This article follows the initial String.intern in Java 6, 7 and 8 – string pooling article describing the implementation and benefits of using
String.intern() method in Java 7 and 8. The original article was already getting too long, so I had to write this article in order to describe the performance characteristics of the multithreaded access to the
The tests we will perform today are calling
String.intern() from the multiple threads. They will emulate the behavior of a lot of modern server applications (for example, specialized web crawlers). For tests I will use my new workstation with Intel Xeon E5-2650 CPU (8 physical, 16 virtual cores @ 2 Ghz) and 128 Gb RAM. It will allow us to test the rather high contention scenarios. In this article we will create 8 threads in order to utilize all physical cores.
There will be 4 tests:
The benchmark one – a single thread calling
testLongLoopmethod from the previous article. It will show us how fast this configuration is without any contention.
All 8 threads are calling
String.intern()with unique values – an own prefix will be added by each thread to the interned string. This test will show us the synchronization overhead of
String.intern(). It should be the theoretical worst case: it is highly unlikely that the only thing the actual application would do is calling
String.internin a loop from many threads.
Initially we start the first thread interning the set of strings. After 2 seconds delay we will start a second thread interning the same set of strings. We expect that the following assumptions will be true:
str.intern()==strfor the first thread;
str.intern()!=strfor the second thread. It will allow us to prove that there are no thread local JVM string pools.
- All 8 threads will intern the same set of values. This scenario will be closer to the real situation – it will provide us the rather likely mix of adding strings to the JVM pool and querying the strings from it. Nevertheless, such a high read contention on the JVM string pool is still an unlikely event.