# Java Lock Implementations

DevFeed: [Java Lock Implementations](<https://devfeed.tech/articles/java-lock-implementations-13620.md>)

Original publisher: [Read original article](<https://mechanical-sympathy.blogspot.com/2011/11/java-lock-implementations.html>)

Author: Martin Thompson (noreply@blogger.com)

Published: 2011-11-19T02:57:00Z

Content type: comparison

Language: en

Sources: [Mechanical Sympathy](<https://devfeed.tech/sources/mechanical-sympathy.md>)

Topics: [Java](<https://devfeed.tech/topics/java.md>), [Concurrency](<https://devfeed.tech/topics/concurrency.md>), [Concurrent Programming](<https://devfeed.tech/topics/concurrent-programming.md>), [x86](<https://devfeed.tech/topics/x86.md>), [Linux](<https://devfeed.tech/topics/linux.md>)

Tags: [concurrent](<https://devfeed.tech/tags/concurrent.md>), [cpu](<https://devfeed.tech/tags/cpu.md>), [java](<https://devfeed.tech/tags/java.md>), [linux](<https://devfeed.tech/tags/linux.md>), [lock-free](<https://devfeed.tech/tags/lock-free.md>), [locking](<https://devfeed.tech/tags/locking.md>), [locks](<https://devfeed.tech/tags/locks.md>), [ordering](<https://devfeed.tech/tags/ordering.md>), [performance](<https://devfeed.tech/tags/performance.md>), [tests](<https://devfeed.tech/tags/tests.md>), [x86](<https://devfeed.tech/tags/x86.md>)

## AI overview

This article compares Java lock implementations, including atomic locking on language monitors, biased locking, and ReentrantLock. It describes a test measuring lock costs under increasing contention on Intel CPUs using Linux and Oracle JDK 1.6.0_29, and recommends measuring applications before choosing JVM lock settings.

## Source excerpt

We all use 3rd party libraries as a normal part of development. Generally, we have no control over their internals. The libraries provided with the JDK are a typical example. Many of these libraries employ locks to manage contention. JDK locks come with two implementations. One uses atomic CAS style instructions to manage the claim process. CAS instructions tend to be the most expensive type of CPU instructions and on x86 have memory ordering semantics. Often locks are un-contended which gives rise to a possible optimisation whereby a lock can be biased to the un-contended thread using techniques to avoid the use of atomic instructions. This biasing allows a lock in theory to be quickly reacquired by the same thread. If the lock turns out to be contended by multiple threads the algorithm with revert from being biased and fall back to the standard approach using atomic instructions. Biased locking became the default lock implementation with Java 6. When respecting the single writer principle, biased locking should be your friend. Lately, when using the sockets API, I decided to measure the lock costs and was surprised by the results. I found that my un-contended thread was incurring a bit more cost than I expected from the lock. I put together the following test to compare the cost of the current lock implementations available in Java 6. The Test For the test I shall increment a counter within a lock, and increase the number of contending threads on the lock. This test will be repeated for the 3 major lock implementations available to Java: Atomic locking on Java language monitors Biased locking on Java language monitors ReentrantLock introduced with the java.util.concurrent package in Java 5. I'll also run the tests on the 3 most recent generations of the Intel CPU. For each CPU I'll execute the tests up to the maximum number of concurrent threads the core count will support. The tests are carried out with 64-bit Linux (Fedora Core 15) and Oracle JDK 1.6.0_29. The C