Most concurrency tutorials drown you in API names. The mental models below are what you need to draw on a whiteboard — five pictures, each one answering a question that eliminates candidates who memorized without understanding.
Picture 1: Two people, two whiteboards, one filing cabinet
Threads are people in separate rooms, each with their own whiteboard (CPU caches), copying from a shared filing cabinet (main memory). Without rules, Person A updates their whiteboard and never files it back; Person B reads stale cabinet files forever.
The Java Memory Model is the office protocol that says when whiteboard changes must be filed and when the cabinet must be re-read. volatile, synchronized, and final are the three filing rules.
Picture 2: The visibility bug that looks like a hang
boolean running = true; while (running) { spin }
The spinning thread's whiteboard says true and no rule forces a re-read. The loop is a person staring at their own outdated note forever.
Production shape: a stuck consumer loop after a shutdown signal. Fix: volatile. Interview follow-up: why doesn't volatile fix count++? (Visibility is not atomicity — read-modify-write is still three interleavable steps.)
Picture 3: CAS as optimistic version-checking
AtomicInteger.incrementAndGet() doesn't lock. It says: I'm writing 5 — only if the current value is still 4. On conflict, retry. No queue, no blocking.
This is Check-And-Set: the hardware-level primitive behind every Atomic class, the entire AQS framework, and every optimistic-locking database transaction.
Picture 4: The four conditions that must ALL hold for deadlock
Two philosophers, each holding one chopstick, each waiting for the other's. The four conditions: mutual exclusion, hold-and-wait, no preemption, circular wait.
You only need to break one. The production fixes map directly:
- Global lock ordering (breaks circular wait)
- tryLock with timeout (breaks no-preemption)
- Shrinking critical sections to single-lock (breaks hold-and-wait)
The classic production corpse: nested synchronized on two entities in a transfer function called in both directions.
Picture 5: The happens-before arrow chain
Your reasoning is only valid if an arrow connects the write you care about to the read you care about. Arrows come from: program order (within a thread), monitor unlock to lock, volatile write to read, thread start and join. They compose.
No arrow = no promise = works on my machine.
The five-panel whiteboard strip
Draw these five in order during an interview and narrate each one: (1) two whiteboards one cabinet, (2) volatile filing rule, (3) CAS version-check, (4) lock ladder, (5) happens-before arrows. Anyone who can do this passes the concurrency screen. Anyone who recites API names doesn't.
I collected twelve of these visual models — from thread memory to production patterns, deadlock to virtual threads — in Java Concurrency, Visualized. If you can draw all five panels, you already know the value.
Top comments (0)