The bank that freezes itself

public final class Account {
    final String id;                 // immutable, unique — the ordering key
    private final ReentrantLock lock = new ReentrantLock();
    private long balance;
 
    Account(String id, long balance) { this.id = id; this.balance = balance; }
 
    ReentrantLock lock() { return lock; }
    long balance()       { return balance; }
    void add(long d)     { balance += d; }   // callers hold the lock
}
 
public final class Bank {
    private final Map<String, Account> accounts;
 
    public void transfer(String from, String to, long amount) {
        Account src = accounts.get(from), dst = accounts.get(to);
        if (src == null || dst == null) throw new NoSuchElementException();
        if (src == dst) return;
 
        Account first = src, second = dst;
        if (first.id.compareTo(second.id) > 0) { first = dst; second = src; }
 
        first.lock().lock();
        try {
            second.lock().lock();
            try {
                if (src.balance() < amount) throw new IllegalStateException("insufficient funds");
                src.add(-amount);
                dst.add(amount);
            } finally { second.lock().unlock(); }
        } finally { first.lock().unlock(); }
    }
}

The ordering rule is identical. Three things about Java are not.

The JVM finds this bug for you, and Go does not. Take a thread dump of the deadlocked program — jstack <pid>, or jcmd <pid> Thread.print — and the output ends with:

Found one Java-level deadlock:
=============================
"pool-1-thread-3":
  waiting to lock monitor 0x00007f... (object 0x...,  a Account),
  which is held by "pool-1-thread-7"
"pool-1-thread-7":
  waiting to lock monitor 0x00007f... (object 0x...,  a Account),
  which is held by "pool-1-thread-3"

That is the cycle, named, with both threads and both objects. ThreadMXBean.findDeadlockedThreads() gives you the same thing programmatically, so you can assert on it in a test or alert on it in production. This works for synchronized monitors and for ReentrantLock. It is one of the genuinely nicer corners of the platform, and it is the reason a Java developer often has an easier time with this specific bug than a Go developer.

synchronized is reentrant, so the self-transfer bug quietly disappears. In Go, Transfer("alice", "alice", 0) locks alice twice and hangs forever. In Java, a thread already holding a monitor can re-enter it, so the same code completes — with a subtle wrongness instead of a hang: the balance is read, decremented, and incremented under one lock acquisition, and the arithmetic happens to cancel out. You do not get punished, which means you do not learn, which means the guard is missing when you later port the logic somewhere non-reentrant. Keep the src == dst check even though Java does not force you to.

try/finally is not optional, and neither is nesting it correctly. Go's defer runs on panic and pairs each release with its acquisition automatically. Java's lock() has no such affordance. Note the nesting above — the inner lock() is inside the outer try, so a failure to acquire the second lock still releases the first, and each finally mentions exactly the lock its own try took. The starter code at the top of this page unlocks second in both blocks, which is how the step-zero bug happens: a permanently held lock, plus an exception raised after the money moved.

The bug is not that two locks are held. It is that different goroutines acquire the same two locks in different orders. Fix the order and the cycle cannot form.

Give every account a stable, unique identity and always lock the lower one first:

type Account struct {
	id      string // immutable, unique
	mu      sync.Mutex
	balance int64
}
 
func (b *Bank) Transfer(from, to string, amount int64) error {
	src, dst := b.accounts[from], b.accounts[to]
	if src == nil || dst == nil {
		return errors.New("no such account")
	}
	// Self-transfer: one lock, or we deadlock against ourselves.
	if src == dst {
		return nil
	}
 
	first, second := src, dst
	if first.id > second.id {
		first, second = second, first
	}
 
	first.mu.Lock()
	defer first.mu.Unlock()
	second.mu.Lock()
	defer second.mu.Unlock()
 
	if src.balance < amount {
		return errors.New("insufficient funds")
	}
	src.balance -= amount
	dst.balance += amount
	return nil
}

Why this works, stated precisely: if every goroutine acquires locks in ascending id order, then a goroutine holding lock X only ever waits for a lock greater than X. A cycle would require some goroutine to wait for a lock smaller than one it holds, which no goroutine ever does. The cycle is not unlikely — it is unconstructible.

The self-transfer case is not a detail. sync.Mutex is not reentrant. Transfer("alice", "alice", 0) on the original code locks alice, then blocks forever waiting for alice — a single goroutine deadlocking against itself. Every lock-ordering scheme needs this guard, and it is the case test suites forget.

Order by identity, never by address. uintptr(unsafe.Pointer(src)) is a tempting one-liner and it is sound for ordering today, but it encodes an assumption about a non-moving garbage collector that is not part of Go's contract. Use a field you control.

The two other fixes, and why they are worse

Try-lock with backoff. Take the first lock, TryLock the second, and if it fails, release the first, back off, retry. This breaks hold-and-wait rather than circular-wait, and it does work. But it converts a correctness property into a performance property: under contention you now have livelock risk and unbounded retries, and the tail latency is nobody's friend. Reach for it only when a stable ordering genuinely is not available.

Go back to one global lock. Correct, trivial, and the thing you were trying to escape. Worth measuring anyway — for a few thousand accounts with short critical sections, the global mutex often wins, because uncontended mutexes are cheap and you have removed all the ordering logic. "Two locks" is a decision that should be earned with a benchmark, not assumed.

import threading
 
class Account:
    def __init__(self, id: str, balance: int) -> None:
        self.id = id                      # immutable, unique
        self.lock = threading.Lock()
        self.balance = balance
 
class Bank:
    def __init__(self, accounts: dict[str, Account]) -> None:
        self._accounts = accounts
 
    def transfer(self, from_id: str, to_id: str, amount: int) -> None:
        src, dst = self._accounts[from_id], self._accounts[to_id]
        if src is dst:
            return
 
        first, second = (src, dst) if src.id < dst.id else (dst, src)
 
        with first.lock:
            with second.lock:
                if src.balance < amount:
                    raise ValueError("insufficient funds")
                src.balance -= amount
                dst.balance += amount

Python's version is the shortest and the worst-behaved when it breaks.

This is the exercise that proves the GIL is not a concurrency strategy. The previous exercise's lost update at least involved the GIL — bytecode granularity was what hid it. Deadlock does not care about the GIL at all. A thread blocked on lock.acquire() releases the GIL while it waits, which is what lets the other thread run and take the second lock. The global interpreter lock neither causes nor prevents this; it is simply irrelevant, and a reader who has been told "Python threading is safe" has no model for why.

Nothing will tell you it happened. There is no jstack, and no equivalent of Go's all goroutines are asleep message — the main thread sits in join() and the process looks alive and idle. Your options are faulthandler.dump_traceback_later(10, exit=False) armed in advance, sending SIGABRT with faulthandler.enable(), or attaching py-spy dump --pid <pid> from outside. Learn py-spy now rather than during an incident; it needs no cooperation from the process.

with is the right tool and the nesting is load-bearing. The nested with blocks release in reverse order on any exception, which is what Go's stacked defers and Java's nested try/finally also achieve. Resist flattening to with first.lock, second.lock: if you ever need a timeout — Lock.acquire(timeout=...) does not compose into the with form, and exercise 07's shutdown work will want it.

threading.Lock is not reentrant, so Python punishes the self-transfer exactly like Go. RLock exists; reach for it deliberately, not to make a hang go away.