Full round replay — deadlock

Pass: Mutual exclusion, hold-and-wait, no pre-emption and circular wait, all four at once. Breaking any one prevents it, and circular wait is the only one you can break without changing what the code does.

Fail: Recites all four with no view on which is practical.

Pass: Sort the two locks by a stable, total key — account id, primary key, path — and take the lower one first in every thread. Three lines, no timeouts, no retries, no coordination between threads.

Fail: Says 'avoid nested locks' or 'use a timeout' without the ordering idea.

Pass: No — it is not guaranteed unique, so two objects can collide and both threads fall back to their own order. If identity is genuinely all you have, use a third tie-breaker lock for the collision case. A business key is better.

Fail: Says yes, or has not considered collisions.

Pass: tryLock with a timeout, releasing everything already held on the way out, then retrying with backoff and jitter. It converts a hang into a failure you now have to handle — worse than ordering, better than stopping.

Fail: Offers tryLock without mentioning releasing the first lock or handling the failure.

Pass: Handle it explicitly — throw, retry with backoff, queue, or return busy. Silently skipping the work is the worst option: under load the system quietly stops doing things and the only symptom is a number that stops adding up.

Fail: Leaves the else branch empty.

Pass: jstack or jcmd Thread.print — it prints 'Found one Java-level deadlock' and names both threads and locks. From inside, ThreadMXBean.findDeadlockedThreads(). Take the dump before restarting, because the restart destroys the evidence.

Fail: Says they would add logging, or restart first.

Pass: Flat CPU, flat heap, and work stopping. A deadlock burns no CPU, so CPU alarms miss it entirely — alert on task completion rate and latency instead.

Fail: Expects high CPU.

Pass: Not one blocked entering a synchronized block. The interrupt flag gets set and the thread stays BLOCKED, because monitor entry is not an interruptible operation. Nothing external frees it — the process restarts. ReentrantLock.lockInterruptibly can be interrupted.

Fail: Thinks interrupt works, or suggests Thread.stop.

Pass: No. synchronized is harder to get wrong because it releases automatically, and the JIT handles it well. Reach for ReentrantLock when you need a timeout, cancellation, several conditions, or acquire and release in different scopes.

Fail: Absolute answer either way.

Pass: No — one thread is holding the lock across something slow, probably a remote call. The detector reports nothing and the service is just as stalled. The fix is to do the I/O outside the lock, not to reorder anything.

Fail: Calls it a deadlock, or has no second hypothesis.

Pass: Same cycle, different ending — the database detects it and kills one transaction, so you get a retryable exception rather than a hang. Prevention is identical: touch rows in a consistent order, keep transactions short, ORDER BY id on bulk updates.

Fail: Assumes the database hangs too.