# Highly contended and fair locking in Java

DevFeed: [Highly contended and fair locking in Java](<https://devfeed.tech/articles/highly-contended-and-fair-locking-in-java-12443.md>)

Original publisher: [Read original article](<http://brooker.co.za/blog/2012/09/10/locking.html>)

Author: Marc Brooker

Published: 2012-09-10T00:00:00Z

Content type: article

Language: en

Sources: [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog.md>), [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog-2.md>)

Topics: [Benchmark](<https://devfeed.tech/topics/benchmark.md>), [Concurrency](<https://devfeed.tech/topics/concurrency.md>), [Concurrent Programming](<https://devfeed.tech/topics/concurrent-programming.md>), [Code](<https://devfeed.tech/topics/code.md>)

Tags: [benchmark](<https://devfeed.tech/tags/benchmark.md>), [java](<https://devfeed.tech/tags/java.md>), [locks](<https://devfeed.tech/tags/locks.md>), [performance](<https://devfeed.tech/tags/performance.md>), [thread](<https://devfeed.tech/tags/thread.md>)

## AI overview

This Java article compares highly contended explicit locking with volatile access using benchmark experiments. It reports substantially higher costs for locking, discusses thread starvation with non-fair ReentrantLock usage, and describes the throughput and fairness trade-offs of fair locks.

## Source excerpt

Highly contended and fair locking in Java How do explicit locks compare to volatile access? In my last post on Java's volatile, I showed how (in one set of experiments) Java volatile variable reads don't come for free. The cost of accessing a highly-contended volatile variable in one micro-benchmark came out at about 100x the cost of accessing a non-volatile variable. How does that compare to locking? In the last post, I presented the results of a program which: Launches 3 reader threads, which do 500 million reads from a shared variable and stores to a local variable Launches 1 writer thread, which increments the shared variable 500 million times Synchronizes their start times, and times them to completion For this post, I modified it to make the variable non-volatile, and add explicit locking using a ReentrantLock. Performance dropped substantially bad. The graph below is an update of the graph from the last post, including the locking version. For reads, the locking version of this test is about 33x more expensive than the volatile version (and over 3000x more than the incorrect unsynchronized version). Writes are about 15x more expensive. To put this in perspective, it's still only 545 nanoseconds per lock operation, so individual operations are not really expensive in absolute terms. The other effect of locking vs. volatile is starvation of threads. The documentation for ReentrantLock says: The constructor for this class accepts an optional fairness parameter. When set true, under contention, locks favor granting access to the longest-waiting thread. Otherwise this lock does not guarantee any particular access order. Programs using fair locks accessed by many threads may display lower overall throughput (i.e., are slower; often much slower) than those using the default setting, but have smaller variances in times to obtain locks and guarantee lack of starvation. In my tests, I had fairness disabled and saw significant thread starvation. In about one run in five