Deadlock, Livelock & Starvation

When everyone is waiting and no one moves

A deadlock is a set of threads each blocked forever, waiting on a lock another of them holds. Throughput goes to zero, nothing crashes, and the stack traces all say "waiting." It's the failure mode of using multiple locks.

The four conditions (all must hold)

Coffman's conditions — remove any one and deadlock is impossible:

1. Mutual exclusion — a resource is held exclusively.
2. Hold and wait — a thread holds one lock while requesting another.
3. No preemption — a lock can't be forcibly taken away.
4. Circular wait — a cycle of threads each waiting on the next.

The textbook reproduction (Java)

// T1: synchronized(A){ synchronized(B){ ... } }
// T2: synchronized(B){ synchronized(A){ ... } }   // opposite order
void t1() { synchronized(A) { sleep(10); synchronized(B) { work(); } } }
void t2() { synchronized(B) { sleep(10); synchronized(A) { work(); } } }
// T1 grabs A, T2 grabs B, then each blocks forever on the other.

The fix: a global lock order (breaks circular wait)

If every thread acquires locks in the same global order, a cycle can never form. Order by any stable key (e.g. System.identityHashCode, or an account id in a transfer):

Lock first = a.id < b.id ? a : b, second = a.id < b.id ? b : a;
synchronized(first) { synchronized(second) { transfer(a, b); } }

Other tactics: tryLock with timeout (break "no preemption" — back off and retry), or a single coarse lock (break "hold and wait"). This is the same cycle you'll see as a database deadlock — the DB just detects it and aborts one transaction as the victim.

In Go

Go has the same lock deadlock with sync.Mutex, but also a built-in safety net: if every goroutine is blocked, the runtime panics — fatal error: all goroutines are asleep - deadlock! The classic channel version is a send with no receiver:

ch := make(chan int)
ch <- 1   // unbuffered, no receiver -> blocks forever -> runtime deadlock panic

Note the runtime only catches total deadlock; a partial deadlock (some goroutines still running) hangs silently, just like Java.

Cousins: livelock & starvation

• Livelock: threads keep reacting to each other and retrying but make no progress (two people stepping aside in a hallway). Fix with randomized backoff.
• Starvation: a thread never gets the resource because others keep winning it (unfair locks, priority). Fix with fair locks / queueing.

Takeaways

• Deadlock needs all four Coffman conditions; break circular wait with a global lock order.
• tryLock + timeout, lock ordering, or one coarse lock are the practical escapes.
• Go detects total deadlock at runtime; partial deadlock hangs in both languages.

---

Re-authored for this guide; wait-for-cycle diagram hand-authored as SVG. Follows Java Concurrency in Practice ch. 10. See also: Mutex Lock, Atomics & CAS, and (Databases) MVCC & deadlocks.

I just read a lesson on **Deadlock, Livelock & Starvation** (Concurrency) and want to truly understand it. Explain Deadlock, Livelock & Starvation from first principles using ONE vivid real-world analogy and a visual mental model — draw it as ASCII art or a clear step-by-step diagram — with a concrete example using real numbers. Then ask me one question to check I got the mental picture, and wait for my reply. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Teach me **Deadlock, Livelock & Starvation** interactively. Ask me ONE guiding question at a time, wait for my answer, and adapt to my confusion — build the idea with me step by step instead of explaining it all at once. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Quiz me on **Deadlock, Livelock & Starvation** with 5 questions, easy to tricky, ONE at a time. Tell me if each answer is right; at the end, explain clearly what I got wrong and why. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Help me remember **Deadlock, Livelock & Starvation** for the long term: give the one-sentence intuition, a memorable hook/mnemonic, a tiny worked example, and 3 active-recall flashcards (Q -> A). If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.