Deadlock and prevention.

Deadlock is the concurrency version of two cars meeting on a narrow bridge and both refusing to reverse — interviewers love it because it tests whether you can keep a system moving, not just make it correct.

Question: What is deadlock, and how do you prevent it in Java?

Answer: Deadlock happens when two or more threads each hold a lock and wait forever for another lock, so none of them can continue. In Java this can happen with either synchronized blocks or explicit locks such as ReentrantLock. Prevention means designing the locking so the cycle cannot form, usually by using one global lock order, keeping locked sections short, or using tryLock with a timeout so a thread can back off instead of waiting forever.

Interview-Ready Answer: I’d define deadlock as a situation where threads are stuck forever because each one is holding a lock and waiting for another lock held by someone else. In Java, it usually appears when multiple locks are acquired in different orders across different code paths. I prevent it by enforcing one global lock order, minimizing the time spent inside critical sections, and, when appropriate, using ReentrantLock.tryLock() with a timeout so a thread can fail fast and retry instead of blocking forever. If I need to debug production, I can confirm the deadlock with a thread dump or ThreadMXBean, but the real fix is to break circular wait in the design.

What deadlock really is

Deadlock is a liveness problem: the code is alive, threads exist, but useful work stops. In Java, a thread can block on an intrinsic monitor from synchronized or on an explicit lock from java.util.concurrent.locks. The important point is that deadlock is not about bad data; it is about a cycle of waiting.

1. Thread A acquires lock X.
2. Thread B acquires lock Y.
3. A tries to get Y and must wait.
4. B tries to get X and must wait.
5. Neither thread reaches its unlock code, so the cycle never breaks.

That is why deadlock is so nasty: the program does not crash, it just stops making progress.

The four conditions you must break

Classic deadlock needs all four of these conditions at the same time:

1. Mutual exclusion — a resource can be held by only one thread at a time.
2. Hold and wait — a thread holds one lock while waiting for another.
3. No preemption — the JVM does not forcibly take a lock away from a thread.
4. Circular wait — Thread A waits for B, B waits for C, and C waits for A.

In practice, the easiest condition to break is circular wait. You do that by making every thread acquire multiple locks in the same order everywhere in the codebase.

How prevention works under the hood

1. Choose a global order. Give every lockable resource a stable order, such as account id, object id, or name.
2. Always lock in that order. If every thread follows the same sequence, a cycle cannot form.
3. Release in reverse order. That keeps the locking discipline easy to reason about.
4. Keep critical sections small. A critical section is the tiny piece of code that needs the lock. The shorter it is, the less chance another thread waits.
5. Use timeout-based locking when ordering is hard. With ReentrantLock.tryLock(), a thread can give up, release what it already holds, and retry later instead of waiting forever.
6. Prefer fewer shared locks. Sometimes the best prevention is to redesign: immutable objects, queues, or atomic variables can remove the need for nested locks altogether.

When to use which prevention strategy

Strategy	Best for	Trade-off
Global lock order	Multiple locks	Needs one rule everywhere
tryLock + timeout	Request code	Retries and possible starvation
Single coarse lock	Small shared state	Lower concurrency
No shared mutable state	New designs	More refactoring

As a rough rule, ordered locking is the cleanest fix when you truly need nested locks. Timeout-based locking is useful when you would rather fail fast than freeze a request. A timeout of tens to hundreds of milliseconds is common in interactive services, but the real value should match your SLA and retry policy.

Performance and edge cases

Ordered locking is usually O(1) extra work per lock if the order key already exists. If you must sort k locks before acquiring them, the extra cost becomes O(k log k). Timeout locking adds O(1) acquisition overhead, but the real cost can be retries, backoff delays, and extra latency. Memory overhead is usually O(1) per lock.

Important gotchas: a fair lock (new ReentrantLock(true)) can reduce starvation, but it does not prevent deadlock. Reentrancy also does not save you from deadlock across different locks; it only means the same thread can re-enter the same lock safely. And if two resources compare equal for ordering, you need a tie-breaker so the order is still deterministic.

If you suspect a production hang, deadlock detection tools help: a thread dump, jstack, or ThreadMXBean.findDeadlockedThreads(). That tells you that you are deadlocked; prevention is still the real fix.

Real-world story

Imagine an e-commerce checkout service that updates an Order record and an Inventory record for every purchase. One code path locks Order first and then Inventory; another path, written later by a different team, locks Inventory first and then Order. Under peak traffic, two requests hit those paths at the same time and each thread waits for the other lock forever.

What does the incident look like? Customers see the spinner never finish, the queue of pending requests grows, and the JVM thread dump shows many threads in BLOCKED or waiting on monitors. CPU may actually be low, which confuses people at first, because the app is not busy doing work — it is stuck waiting. The fix is to enforce one lock order everywhere, and if the second update is optional, use a timeout and retry instead of freezing the whole request.

A small misunderstanding of lock order can turn into a large outage: orders pile up, payment webhooks retry, and support sees “my card was charged but the page hung.” Deadlock prevention is not just a theory question; it is a production safety skill.

Follow-up & Tricky Questions

• How is deadlock different from starvation? Deadlock means threads are stuck waiting on each other in a cycle. Starvation means a thread is repeatedly denied access and may wait a very long time, but the system as a whole is still moving.
• Does synchronized prevent deadlock? No. It only guarantees mutual exclusion for one monitor; you can still deadlock if you take multiple monitors in inconsistent orders.
• How do you detect deadlock in a running JVM? Use a thread dump, jstack, or ThreadMXBean.findDeadlockedThreads(). That helps you confirm the problem, but it is detection, not prevention.
• Why does lock ordering work? If every thread acquires resources in the same order, you cannot create a cycle in the wait graph. No cycle means no deadlock.
• When would you prefer tryLock over a normal lock? Use it when waiting forever is worse than failing fast, such as request handlers, batch jobs with retries, or operations that can safely back off.
• Can fair locks solve deadlock? No. A fair lock only changes who gets the lock next; it does not remove circular wait, so deadlock can still happen.
• Can the same thread deadlock itself? Not with reentrant Java locks on the same monitor, because reentrancy allows the same thread to acquire it again. Self-deadlock usually appears when a thread waits on a condition or another lock it can never reach.
• What is a subtle gotcha with ordering? The order must be global and consistent across all code paths, not just inside one class. If one library sorts by id and another sorts by name, the cycle can still happen.

Common Mistakes

• Thinking "I used synchronized, so I’m safe" — correction: synchronized makes each individual lock safe, but multiple locks can still deadlock.
• Forgetting a global lock order — correction: every path that touches the same resources must follow the same ordering rule.
• Holding locks while calling slow code — correction: do not call network, database, or user code while holding multiple locks unless you absolutely must.
• Using fair locks as a magic fix — correction: fairness may help starvation, but it does not prevent deadlock.

Memory Hook

Memory Hook: Think of a four-way stop where every car has already entered the intersection and nobody is allowed to reverse. Deadlock prevention means deciding the right order before you enter the intersection.

Cheat Sheet

• Deadlock = threads wait forever in a cycle.
• Java deadlocks can happen with synchronized and ReentrantLock.
• Best prevention: one global lock order.
• Good backup: tryLock with timeout and retry/backoff.
• Keep critical sections short.
• Fair locks help scheduling, not deadlock.

Practice Tasks

• Write two methods that lock Account objects in opposite order, then fix them with a shared ordering rule.
• Change the demo to use three locks instead of two and sort them by id before acquiring them.
• Add retry logic with a small random backoff after a tryLock timeout and observe how it reduces collisions.