How Java’s AQS Powers ReentrantLock: Deep Dive into Lock Implementation

1. Lock Interface

In a previous article we introduced using Lock objects to achieve synchronization similar to the synchronized keyword, but with explicit lock acquisition and release, offering features such as interruptible and timed lock acquisition.

Lock enables complex acquisition sequences (e.g., acquire A, then B, release A, acquire C, etc.) that would be cumbersome and error‑prone with synchronized.

The following diagram shows the location of lock‑related classes in the Java 8 java.util.concurrent.locks package.

The inheritance relationship among these classes is illustrated below.

The primary implementation of Lock is ReentrantLock, which relies on AbstractQueuedSynchronizer (AQS) as its core synchronization framework.

2. AbstractQueuedSynchronizer (AQS)

AQS is a framework for building locks and other synchronizers. It maintains an int state variable and a built‑in FIFO queue to manage threads waiting for the lock.

Two key aspects are exposed:

Understanding the current synchronization state of a shared variable.

Queueing threads that cannot acquire the lock, using the internal FIFO queue.

Subclasses extend AQS and override its abstract methods to manipulate the synchronization state. The three core methods used by subclasses are getState(), setState(), and compareAndSetState().

AQS supports both exclusive and shared acquisition modes, enabling implementations such as ReentrantLock, ReentrantReadWriteLock, and CountDownLatch.

AQS defines several categories of methods:

protected methods that subclasses may override (e.g., tryAcquire, tryRelease).

public final template methods that provide the external API (e.g., acquire, release).

protected final methods for low‑level state manipulation.

AQS also contains two important inner classes: ConditionObject (implementing Condition) and Node, which represents a thread waiting in the queue.

3. ReentrantLock Design and Implementation

The class diagram of ReentrantLock shows three static inner classes: Sync, NonfairSync, and FairSync. Sync extends AbstractQueuedSynchronizer, while the two concrete subclasses implement the lock acquisition policy.

Sync

overrides only tryRelease (and tryAcquire in the concrete subclasses). FairSync provides a fair acquisition algorithm by overriding tryAcquire and delegating to the AQS acquire method.

4. Building a Custom Lock with AQS

To create a custom lock, implement the Lock interface and define an inner class that extends AbstractQueuedSynchronizer, overriding the necessary methods ( tryAcquire, tryRelease, etc.). The following schematic shows the implementation steps.

A simple test case demonstrates that the custom lock behaves like ReentrantLock (though it lacks the non‑fair and fair variants).

Adding a fair lock variant would follow the same pattern as the standard ReentrantLock implementation.