Master Java Lock Optimization: Reduce Contention with AQS & ReentrantLock

Java Queue Synchronizer (AQS) and ReentrantLock Principles Overview

Background

In a previous article we introduced the JVM's lock‑optimization efforts, covering biased locks, lightweight locks, heavyweight locks, and spin locks.

We also discussed two main ways to ensure data safety in multithreaded environments: locking (time‑for‑space) and ThreadLocal (space‑for‑time), and the pitfalls of improper ThreadLocal usage.

Why Further Explore Locks

Lock contention and context switching under high concurrency can degrade performance, so there is room for optimization.

Lock‑Optimization Recommendations

1. Reduce Lock Hold Time

Only the method mutextMethod() needs synchronization; method1() and method2() do not. If the latter two are time‑consuming, holding the lock for them is inefficient. Synchronize only the necessary part to shorten lock duration and boost performance.

By synchronizing only when needed, lock hold time is reduced, improving system performance.

2. Reduce Lock Granularity

HashTable uses a single lock for all operations, causing severe contention. ConcurrentHashMap introduces lock segmentation: the map is divided into multiple segments, each with its own lock, allowing concurrent access to different segments.

By default, ConcurrentHashMap has 16 segments (locks), enabling high concurrency—a typical example of reducing lock granularity.

3. Replace Exclusive Locks with Read‑Write Locks

ReentrantLock provides exclusive mutual exclusion via ReentrantLock.lock(). For scenarios where many reads occur, ReentrantReadWriteLock offers a shared read lock and an exclusive write lock, allowing multiple concurrent reads while still protecting writes. ReentrantReadWriteLock has two locks: a shared read lock and an exclusive write lock. When no thread is writing, multiple threads can acquire the read lock simultaneously; only one thread can hold the write lock at a time.

4. Lock Splitting

Extending the read‑write lock idea, lock splitting separates independent operations into different locks. For example, LinkedBlockingQueue uses separate takeLock and putLock for the head and tail operations, allowing true concurrent puts and takes.

5. Lock Coarsening

When the overhead of acquiring and releasing locks for several short operations exceeds the execution time of those operations, it can be beneficial to merge them under a single lock. This reduces context switches and can improve overall execution time.

6. Lock Elimination

At the JIT compilation stage, if the compiler determines that an object is never shared between threads, it can eliminate the associated lock operations, removing unnecessary synchronization.

Even classes like Vector and StringBuffer contain synchronized methods, but the JVM may eliminate those locks when it proves the objects are thread‑confined.

7. JVM‑Level Lock Optimizations

For deeper details, refer to the previous article on how the JVM optimizes locks from the perspective of volatile and synchronized.