The bank that loses money

public final class Bank {
    private final Map<String, Long> balances = new HashMap<>();
 
    public Bank() {
        balances.put("alice", 1000L);
        balances.put("bob", 1000L);
    }
 
    public synchronized void transfer(String from, String to, long amount) {
        long src = balances.getOrDefault(from, 0L);
        if (src < amount) return;              // check and act, together
        balances.put(from, src - amount);
        balances.merge(to, amount, Long::sum);
    }
 
    public synchronized long total() {
        return balances.values().stream().mapToLong(Long::longValue).sum();
    }
}

The shape is the same as Go's. What differs is everything around it.

ConcurrentHashMap would not have fixed this, and that is the trap. It is the first thing a Java developer reaches for, and it makes every individual get and put thread-safe. The transfer is neither: it is a get, a compare, a put, and another put. A concurrent map guarantees each step is safe and says nothing about the four of them together. You would trade a possibly-corrupt map for a reliably-wrong ledger — and you would have removed the only symptom that was telling you something was wrong.

Java will not crash the way Go does. HashMap under concurrent write does not throw; it silently drops entries, and historically could spin forever in get on a cyclic bucket chain. There is no -race flag. The nearest equivalents are jcstress for targeted concurrency tests and ThreadSanitizer via -XX:+UseTSAN on recent builds, and neither is something you have running by default. Java's default posture on this bug is silence.

A non-volatile long is not guaranteed to be read atomically. This is the genuinely startling one, and it has no analogue in the Go exercise above. Section 17.7 of the JLS permits a 64-bit read or write to be split into two 32-bit halves, so an unsynchronised reader can observe a long that is the high half of one value and the low half of another — a number that was never written by anybody. A 64-bit HotSpot will not actually do this, but the guarantee is not in the language, and "my JVM happens not to" is not a property you want a ledger resting on.

Visibility is a separate guarantee from atomicity. Even if the increment were atomic, without a happens-before edge between the writing and reading threads the JMM does not require the reader to ever observe the write. Not "later" — ever. synchronized gives you mutual exclusion and that edge in the same construct, which is why it is the right tool here and why volatile alone is not: volatile fixes visibility and leaves -= as broken as before.

synchronized methods versus a private lock. Locking on this publishes your lock: any caller holding a Bank reference can synchronized (bank) { ... } and block your transfers. For real code, prefer a private final Object lock (or a ReentrantLock when you need tryLock or a timeout — which exercise 02 will need).

Guard the whole operation, not the individual writes:

type Bank struct {
	mu       sync.Mutex
	balances map[string]int64
}
 
func (b *Bank) Transfer(from, to string, amount int64) {
	b.mu.Lock()
	defer b.mu.Unlock()
 
	if b.balances[from] < amount {
		return
	}
	b.balances[from] -= amount
	b.balances[to] += amount
}
 
func (b *Bank) Total() int64 {
	b.mu.Lock()
	defer b.mu.Unlock()
 
	var sum int64
	for _, v := range b.balances {
		sum += v
	}
	return sum
}

Three things worth saying explicitly, because they are the actual content of this exercise.

The critical section is the invariant, not the statement.

It is tempting to lock around each line, or reach for atomic.AddInt64 on each balance. Both are wrong here, in an instructive way:

• Atomic adds make each individual write indivisible, so no single unit is lost.
• But between the debit and the credit, the money exists in neither account.
• Total() can observe exactly that moment and report 1999.

The thing that must be atomic is the transfer, because the invariant you promised is about the pair.

Total() needs the lock too. A reader that does not synchronise is still racing, and -race will tell you so. A lock held only by writers protects writers from each other and nobody from the readers.

The overdraft check is a separate bug, and the mutex is what fixed it. Look at the original:

if b.balances[from] < amount { return }
b.balances[from] -= amount

That is check-then-act. Between the check and the act, another goroutine can drain the account, and the balance goes negative — an overdraft the code explicitly tried to prevent. This bug is not a data race and the race detector will not always point at it; it is a logic error that exists because the decision and the action were not taken together. Had you "fixed" the first problem with atomic adds, you would have kept this one. The mutex fixes both precisely because it makes check-and-act a single unit.

import threading
 
class Bank:
    def __init__(self) -> None:
        self._lock = threading.Lock()
        self._balances = {"alice": 1000, "bob": 1000}
 
    def transfer(self, src: str, dst: str, amount: int) -> None:
        with self._lock:
            if self._balances[src] < amount:
                return
            self._balances[src] -= amount
            self._balances[dst] += amount
 
    def total(self) -> int:
        with self._lock:
            return sum(self._balances.values())

Python is the language where this exercise is hardest to believe, because the GIL means only one thread runs bytecode at a time, and that sounds like it should make the problem go away.

What the GIL actually promises. It serialises the interpreter, so a single bytecode instruction is never interleaved. dict insertion will not corrupt the dict, which is why Python never crashes here the way Go does. That is the whole guarantee.

What the transfer needs. self._balances[src] -= amount compiles to a load, a subtract, and a store — several bytecodes. The interpreter can switch threads between any two of them (every 5ms by default; see sys.setswitchinterval). So you get precisely the lost update from the Go version, at exactly the same rate, with none of the noise.

>>> import dis; dis.dis("d['a'] -= 1")
  LOAD_NAME    d        # thread switch possible here
  LOAD_CONST   'a'
  ...
  BINARY_OP    -=       # ...and here
  STORE_SUBSCR           # ...and here

Make the failure visible. With the default switch interval the race is real but infrequent. sys.setswitchinterval(1e-6) turns it into a near-certainty, which is Python's equivalent of the time.Sleep trick used in the next exercise.

The GIL is a property of CPython, not of Python. Python 3.13 shipped an officially supported free-threaded build (PEP 703) and 3.14 made it a fully supported configuration. On a free-threaded interpreter the serialisation is gone, dict is protected by its own internal locking rather than a global one, and code that was accidentally surviving on GIL granularity stops surviving. If you have ever heard "Python threads are safe because of the GIL", this is the exercise that ends that belief: the GIL was never making your compound operations atomic, it was only making them look atomic often enough to pass your tests.

threading.Lock is not reentrant. Same as Go's mutex, unlike synchronized in Java. If transfer ever calls another locked method on the same object you will deadlock against yourself — use threading.RLock when you genuinely need that, and be suspicious of why you do.