ReentrantLock.

When a lock looks simple, the interview gets tricky: ReentrantLock gives you the same safety as synchronized, but with more control.

Question: What is ReentrantLock in Java?

Answer: ReentrantLock is a mutual-exclusion lock, or mutex, that lets only one thread at a time enter a critical section. It is called reentrant because the same thread can acquire it more than once without deadlocking itself. You must release it the same number of times, usually in a finally block.

Interview-Ready Answer: “ReentrantLock is a thread lock from java.util.concurrent.locks that works like synchronized, but with extra control. The same thread can lock it repeatedly, and each acquisition increases an internal hold count that must be unlocked the same number of times. I use it when I need things like tryLock(), timeout, interruptible waiting, or a fair queue.”

What it is

ReentrantLock lives in java.util.concurrent.locks. Think of it as a mutex with extra controls: it protects a shared invariant, and it can be entered again by the same owner thread.

How it works under the hood

1. The lock keeps track of an owner thread and a hold count.
2. When a thread calls lock(), it first tries a fast path: if the lock is free, it atomically claims it.
3. If the current thread already owns the lock, the hold count increases instead of blocking.
4. If another thread owns it, the caller is placed into a queue managed by AQS (AbstractQueuedSynchronizer), a framework that keeps a wait queue plus a small integer state.
5. The waiting thread parks, which means the scheduler suspends it until it is woken up or interrupted.
6. On unlock(), the hold count decreases. When it reaches zero, ownership is cleared and one waiting thread is unparked.
7. With a fair lock, queued threads are preferred. With a non-fair lock, a fresh thread may barge in and win the race.
8. The same thread may lock multiple times, but it must unlock the same number of times. If a different thread calls unlock(), Java throws IllegalMonitorStateException.

When and why to use it

• You need tryLock() to avoid waiting forever.
• You need lockInterruptibly() so a request can be cancelled while waiting.
• You need fairness for long-waiting threads, even if throughput drops a bit.
• You need multiple wait queues with Condition objects, such as notEmpty and notFull.

ReentrantLock vs synchronized

Performance and complexity

In the uncontended case, lock and unlock are O(1). The real cost is contention: blocked threads may park and unpark, which can cost microseconds to milliseconds depending on CPU load and scheduling. Fair locks usually reduce throughput because they limit barging and increase context switches. The default constructor is non-fair (new ReentrantLock()), which is usually the best throughput choice.

Space use is small for the lock object itself, but each blocked thread adds queue bookkeeping and the thread's own stack, which is often around 1 MB by default on many HotSpot setups, though it is configurable.

Edge cases to remember

• tryLock() can fail even if the lock becomes free a moment later.
• tryLock() on a fair lock can still barge; it does not fully obey fairness rules.
• unlock() must be in finally, or an exception can leak the lock.
• isHeldByCurrentThread() and getHoldCount() help with debugging nested locking.

Real-World Example: In a checkout service, several request threads update an in-memory inventory cache. One method reserves stock, another applies a promo, and both must protect the same state. A ReentrantLock makes the critical section explicit, and tryLock(50, TimeUnit.MILLISECONDS) can fail fast if the system is overloaded instead of piling up requests.

What goes wrong when people misunderstand it: a developer acquires the lock, hits an exception, and forgets the finally release. After that, every checkout thread waits behind the stuck owner. The user symptom is a spinning payment page; the logs show threads blocked on ReentrantLock, the p99 latency climbs, and a thread dump reveals many threads in WAITING state. The outage is not a crash; it is a traffic jam caused by one unreleased lock.

Follow-up & Tricky Questions:

• What does reentrant mean? It means the same thread can enter the same lock more than once. The lock stores a hold count, so nested calls do not deadlock the owner thread.
• Why would you choose a fair lock? Use fairness when starvation would hurt correctness or user experience, such as long-lived tasks that should not be skipped forever. The trade-off is usually lower throughput.
• What is the difference between lock() and lockInterruptibly()? lock() waits until the lock is available and does not respond to interrupts while waiting. lockInterruptibly() can stop waiting and throw InterruptedException.
• Why use Condition instead of wait/notify? A Condition gives you a separate wait queue per reason, such as notEmpty and notFull. That makes the code easier to reason about than one shared monitor wait set.
• How do you debug lock contention? Start with thread dumps, JFR, or profiling. You are looking for threads parked on the lock, long hold times, or code paths that fail to release the lock.
• Does a fair lock guarantee exact FIFO order? Not perfectly. It improves ordering for queued threads, but scheduling, interrupts, and timed waits can still change who runs first.
• Can one thread unlock a lock owned by another thread? No. Java throws IllegalMonitorStateException, which is why unlock must happen in the same thread that acquired it.
• Does tryLock() respect fairness? No. Even on a fair lock, tryLock() can barge in if the lock happens to be free at that instant.

Common Mistakes:

• Forgetting unlock() in finally — correction: always release the lock in a finally block so exceptions cannot leak it.
• Assuming fairness means perfect order — correction: fair mode reduces barging, but it does not create a strict guaranteed queue under all conditions.
• Using a lock for every tiny read — correction: only protect the shared invariant; too much locking hurts throughput.
• Confusing reentrancy with thread safety — correction: reentrancy only means the same thread can re-acquire the lock, not that your whole class is automatically safe.

Memory Hook: Think of ReentrantLock as a door with a stamp. The same person can come back in if they already have the stamp, but every entry must be matched with one exit.

Cheat Sheet:

• Same thread can re-acquire the lock.
• Unlock exactly as many times as you locked.
• Use tryLock() for fast failure.
• Use lockInterruptibly() for cancellable waits.
• Default is non-fair and usually faster.
• Use Condition for multiple wait states.

Practice Tasks:

1. Wrap a shared List with a ReentrantLock and protect add/remove operations.
2. Add a tryLock timeout so your method returns a friendly message instead of blocking forever.
3. Write a method that acquires the same lock twice, then verify the hold count changes and reaches zero only after two unlocks.