Explicit Locks - Java Concurrency in Practice - page 328

Figure 13.2. Fair Versus Nonfair Lock Performance.
One reason barging locks perform so much better than fair locks under heavy contention is
that there can be a significant delay between when a suspended thread is resumed and when
it actually runs. Let's say thread A holds a lock and thread B asks for that lock. Since the lock
is busy, B is suspended. When A releases the lock, B is resumed so it can try again. In the
meantime, though, if thread C requests the lock, there is a good chance that C can acquire the
lock, use it, and release it before B even finishes waking up. In this case, everyone wins: B
gets the lock no later than it otherwise would have, C gets it much earlier, and throughput is
improved.
Fair locks tend to work best when they are held for a relatively long time or when the mean
time between lock requests is relatively long. In these cases, the condition under which bar-
ging provides a throughput advantage—when the lock is unheld but a thread is currently wak-
ing up to claim it—is less likely to hold.
Like the default ReentrantLock , intrinsic locking offers no deterministic fairness guaran-
tees, but the statistical fairness guarantees of most locking implementations are good enough
for almost all situations. The language specification does not require the JVM to implement
intrinsic locks fairly, and no production JVMs do. ReentrantLock does not depress lock
fairness to new lows—it only makes explicit something that was present all along.