How to Avoid Deadlock in Java — Lock Ordering, tryLock, and Design Techniques

Deadlock requires all four Coffman conditions simultaneously — break any one and you're safe.

1. Lock ordering — the cornerstone

• Always acquire multiple locks in the same global order
• Order by identity hash: System.identityHashCode(obj) — smaller first
• Or by domain ID: account.id — lower ID first
• Or by documented precedence: "User before Order before Inventory"
• Zero runtime cost; deadlock impossible by construction
• Handle rare hash collisions with a tie-breaker lock

2. tryLock with timeout and back-off

• ReentrantLock.tryLock(1, SECONDS) — returns false if unavailable
• If can't get both locks, release what you have and retry
• No thread ever blocked while holding another lock
• Risk: livelock if two threads keep retrying in lockstep — add randomized Thread.sleep back-off
• tryLock(timeout) with a finite timeout lets you fail fast and return an error

3. Open calls

• Never call external methods while holding a lock
• Listeners, callbacks, other services — all unknown code
• They might acquire other locks or call back into you
• Pattern: copy collections under lock, iterate without:

  snapshot = copyOf(listeners);
  // release lock
  for (l : snapshot) l.onUpdate();

• Straight from Brian Goetz's Java Concurrency in Practice

4. Reduce lock scope

• Smaller critical sections = fewer opportunities for ordering bugs
• Never include I/O, heavy CPU, external calls, or sleep inside a lock
• Use pattern: compute outside, update inside

5. Lock-free alternatives

• ConcurrentHashMap with computeIfAbsent — atomic, lock-free for typical ops
• AtomicReference with updateAndGet — CAS-based
• Immutable data + volatile reference swap — readers never lock
• CopyOnWriteArrayList for read-heavy structures
• Ultimate avoidance: no locks, no deadlock possible

6. Single global lock

• One lock for the whole system
• No cycles possible (only one lock)
• Fine for simple, low-contention systems
• Doesn't scale but gives correctness

Java 21 specific — prefer `ReentrantLock`

• synchronized pins virtual threads to carriers
• Under load: carrier starvation
• ReentrantLock uses Loom-aware LockSupport.park — unmounts cleanly
• Also has tryLock, Condition, fairness options

Monitoring in production

• ManagementFactory.getThreadMXBean().findDeadlockedThreads() on a 30-60s schedule
• Alert on-call when it fires
• Capture thread dump automatically

Common deadlock sources to audit

• Transfers between two objects each with their own lock
• Nested services holding locks during callbacks
• ConcurrentHashMap.computeIfAbsent lambda that acquires another lock (bucket lock + extra lock = potential cycle)
• Static initializers with cross-class dependencies
• Shutdown sequences holding locks across pool termination

Recommendation: Adopt lock ordering as the default for any code that acquires multiple locks — order by identity hash or domain key, document the rule, enforce in code review. Layer in `tryLock(timeout)` for graceful degradation under extreme contention. Apply the open-calls principle ruthlessly: copy collections under lock, iterate without; never hold a lock across a listener callback or external call. For most shared state, reach for lock-free alternatives first — ConcurrentHashMap, AtomicReference, immutable-plus-swap; they sidestep the whole class of problems. On Java 21+, default to ReentrantLock over synchronized. And run `ThreadMXBean.findDeadlockedThreads()` as a scheduled health check so the first time a deadlock ever forms in production, you get paged instead of learning about it from customer complaints.