Deep Dive into ReentrantLock: Fair Lock vs Non-Fair Lock Implementation Principles

This article provides an in-depth analysis of Java's ReentrantLock, focusing on the differences between fair locks and non-fair locks in the JUC (java.util.concurrent) package.

Fair Lock: Multiple threads acquire locks in the order they requested. Threads obtain locks following a first-come-first-served principle, like queuing.

Non-Fair Lock: The order in which multiple threads acquire locks is uncertain. When a thread releases the lock, newly requesting threads may immediately acquire the lock regardless of waiting threads.

ReentrantLock implements Lock interface and Serializable, with three internal classes: Sync (abstract class implementing AbstractQueuedSynchronizer/AQS), NonfairSync, and FairSync. The default constructor creates a non-fair lock; passing true to the parameterized constructor creates a fair lock.

Lock Acquisition Process: The lock() method delegates to sync.lock(). FairSync.lock() directly calls AQS.acquire(), while NonfairSync.lock() first attempts to acquire via CAS. If successful, it sets the current thread as the owner; if failed, it calls acquire(). The acquire() method calls tryAcquire(), addWaiter(), and acquireQueued() to handle lock acquisition, queue waiting, and thread suspension.

Key Difference: Fair lock's tryAcquire() adds a hasQueuedPredecessors() check - if there are waiting threads in the queue, it lets them proceed first. Non-fair lock skips this check, allowing threads to acquire locks without joining the queue.

Unlock Process: unlock() calls AQS.release(), which invokes tryRelease() to release the lock and unparkSuccessor() to wake the next waiting thread.

Why Non-Fair Lock Performs Better: 1) Threads can acquire locks without joining the queue, avoiding thread blocking/waking overhead. 2) Reduces CAS competition - if all threads must join the queue, CAS competition becomes intense.

Choosing Between Them: Fair lock ensures waiting threads won't starve but has lower throughput; suitable for scenarios requiring strict access order. Non-fair lock offers higher throughput but may cause thread starvation; suitable for high-concurrency scenarios without strict ordering requirements.