AQS (AbstractQueuedSynchronizer): How ReentrantLock Actually Works

AQS — AbstractQueuedSynchronizer — is the shared infrastructure underneath almost every lock class in java.util.concurrent. It provides two things: a volatile int state, and a FIFO CLH-style queue of waiting threads. Subclasses define what state means. ReentrantLock uses state as the hold count. Semaphore uses it as remaining permits. CountDownLatch uses it as the remaining countdown. The acquire flow: a thread calls tryAcquire (which subclasses implement, typically a CAS on state — for ReentrantLock, CAS state from 0 to 1). If tryAcquire succeeds, the thread owns the resource. If it fails, AQS enqueues a Node representing this thread into the CLH queue, then parks the thread via LockSupport.park(). The release flow: the holder calls tryRelease, which subclasses implement (for ReentrantLock, decrement state; when it hits 0, null out the exclusive owner); if tryRelease succeeds and the queue is non-empty, AQS unparks the head's next node, which then re-runs tryAcquire and, on success, takes over. CLH queue details: doubly linked list of Node objects. Each Node has prev, next, thread, and waitStatus. Head is a dummy sentinel; the first real waiter is head.next. Threads spin-then-park while waiting. On cancellation or interruption, the node is marked cancelled and eventually spliced out. ReentrantLock itself has two subclasses — FairSync and NonfairSync. Nonfair (default) tries to barge: a new thread can call tryAcquire and steal the lock even if the queue has waiting threads. Fair tryAcquire first checks hasQueuedPredecessors() and skips acquire if anyone is ahead. Nonfair has higher throughput; fair prevents starvation. ReentrantReadWriteLock is a clever trick — it packs write count in the low 16 bits of state and read count in the high 16 bits, so a single CAS can represent both. Understanding AQS lets you read the JDK source for any lock in java.util.concurrent, and also lets you build custom synchronizers by subclassing.