What is ReentrantLock, and how does it differ from the synchronized keyword?

## The problem locks solve When multiple **threads** (independent paths of execution running concurrently) read and write the same data, their operations can interleave and corrupt that data — a **race condition**. A **lock** (also called a **mutex**, for mutual exclusion) fixes this: only one thread may hold the lock at a time, so the code it guards (the **critical section**) runs as if single-threaded. Java has had a built-in locking mechanism since version 1.0: the **`synchronized`** keyword. Every Java object carries a hidden lock called its **intrinsic lock** or **monitor**. Writing `synchronized(obj) { ... }` acquires `obj`'s monitor on entry and releases it on exit (including when an exception is thrown). It is simple and the release is automatic. ## What ReentrantLock is Java 5 added `java.util.concurrent.locks.ReentrantLock`, an **explicit lock**: a plain object implementing the `Lock` interface that you acquire and release with method calls instead of a language keyword. ```java Lock lock = new ReentrantLock(); lock.lock(); // acquire try { // critical section } finally { lock.unlock(); // release — MUST be in finally } ``` **"Reentrant"** means a thread that already holds the lock can acquire it again without deadlocking itself; the lock keeps a hold count and only truly releases when `unlock()` has been called as many times as `lock()`. This matters when one guarded method calls another guarded method on the same object. (Note: `synchronized` is *also* reentrant — the name just makes the property explicit.) ## Why ReentrantLock exists — the extra powers `synchronized` can only do one thing: block until it gets the lock, with no way to give up, time out, or be interrupted. `ReentrantLock` exposes a richer API: - **`tryLock()`** — attempt to acquire and return immediately with `true`/`false` instead of blocking. Lets you take an alternative action rather than wait. - **`tryLock(time, unit)`** — wait up to a bounded time, then give up. Prevents indefinite stalls. - **`lockInterruptibly()`** — block, but throw `InterruptedException` if the thread is interrupted while waiting, so a waiting thread can be cancelled. A thread blocked on `synchronized` cannot be interrupted out of the wait. - **Fairness** — `new ReentrantLock(true)` grants the lock in roughly first-come-first-served order; the default (`false`) is unfair and faster. - **Multiple `Condition`s** — `lock.newCondition()` creates a named wait-set; you can have several per lock (e.g. "not full" and "not empty" for a bounded buffer), whereas `synchronized` gives every object exactly one wait-set via `wait()`/`notify()`. - **Introspection** — `isLocked()`, `isHeldByCurrentThread()`, `getHoldCount()`, `getQueueLength()`. ## The trade-off The price for this power is **manual release**. With `synchronized`, the JVM releases the monitor automatically at the end of the block no matter how you leave it. With `ReentrantLock`, if you forget `unlock()`, or an exception skips it, the lock stays held forever and every other thread blocks permanently — a classic deadlock. Hence the iron rule: **always `unlock()` in a `finally`**, and call `lock()` *outside* the try (if `lock()` itself threw, you'd wrongly unlock a lock you never acquired). ## Which to choose Guidance from *Effective Java* and *Java Concurrency in Practice*: **prefer `synchronized`** for its simplicity and automatic release. Reach for `ReentrantLock` only when you genuinely need one of its extra features — a timeout, interruptible acquisition, fairness, non-blocking attempts, or multiple condition wait-sets. Performance is no longer a deciding factor: modern JVMs optimize uncontended `synchronized` heavily, and the two are comparable. ## Under the hood `ReentrantLock` is built on `AbstractQueuedSynchronizer` (AQS), a framework that maintains an atomic integer state (the hold count) plus a FIFO queue of waiting threads, using compare-and-swap for the fast uncontended path and `LockSupport.park` to suspend contended threads. You don't need this to use it, but it explains where fairness, the queue, and the hold count come from.