Diagnose why two worker threads stopped making progress in this thread dump

Analysis

The dump gives you everything in four lines. Each thread has a locked / waiting to lock pair:

worker-1:  locked <0x…41180>   waiting to lock <0x…3f2c8>
worker-2:  locked <0x…3f2c8>   waiting to lock <0x…41180>

The addresses cross: the monitor one thread holds is exactly the one the other is waiting for, and vice versa. Both are BLOCKED (on object monitor), so neither will release what it holds until it gets what it wants. That closed wait cycle is a deadlock. The CPU is idle because a thread blocked on a monitor does not spin — it sleeps.

Where the cycle comes from. transfer(from, to) synchronizes on from first and to second — the caller's argument order. Two opposite transfers (A→B and B→A) take the same two Account monitors in opposite orders, and the cycle closes.

// ❌ the caller decides the lock order
void transfer(Account from, Account to, long amount) {
    synchronized (from) {
        synchronized (to) { from.debit(amount); to.credit(amount); }
    }
}

// ✅ one global order — the cycle cannot form
void transfer(Account from, Account to, long amount) {
    Account first  = from.id() < to.id() ? from : to;
    Account second = from.id() < to.id() ? to   : from;
    synchronized (first) {
        synchronized (second) { from.debit(amount); to.credit(amount); }
    }
}

When a global order cannot be defined, the alternative is ReentrantLock.tryLock with a timeout: a thread that fails to take the second lock releases the first and retries after a randomized back-off.

⚠️ Trap: growing the pool or raising thread priority does not help — the new threads just queue behind the same monitors. For this case jstack also prints a ready-made Found one Java-level deadlock: line listing the members of the cycle.