Performance and Scalability - Java Concurrency in Practice - page 268

stooges and its internal state never escape, and therefore that all four lock acquisitions can
be eliminated. [4]
Listing 11.3. Candidate for Lock Elision.
Even without escape analysis, compilers can also perform lock coarsening , the merging
of adjacent synchronized blocks using the same lock. For getStooge-Names , a
JVM that performs lock coarsening might combine the three calls to add and the call to
toString into a single lock acquisition and release, using heuristics on the relative cost of
synchronization versus the instructions inside the synchronized block. [5] Not only does
this reduce the synchronization overhead, but it also gives the optimizer a much larger block
to work with, likely enabling other optimizations.
Don't worry excessively about the cost of uncontended synchronization. The basic mechan-
ism is already quite fast, and JVMs can perform additional optimizations that further reduce
or eliminate the cost. Instead, focus optimization efforts on areas where lock contention actu-
ally occurs.
Synchronization by one thread can also affect the performance of other threads. Synchroniz-
ation creates traffic on the shared memory bus; this bus has a limited bandwidth and is shared
across all processors. If threads must compete for synchronization bandwidth, all threads us-
ing synchronization will suffer. [6]
11.3.3. Blocking
Uncontended synchronization can be handled entirely within the JVM ( Bacon et al., 1998 ) ;
contended synchronization may require OS activity, which adds to the cost. When locking is
contended, the losing thread(s) must block. The JVM can implement blocking either via spin-
waiting (repeatedly trying to acquire the lock until it succeeds) or by suspending the blocked