The Java Memory Model is not a diagram of the heap and stack.
It is the contract that decides what one thread is legally allowed to observe from another thread despite CPU caches, compiler optimisation, instruction reordering and concurrent execution.
This visual follows the complete reasoning path:
1 Java Code + Threads
Your source code has program order, but the compiler, JIT and CPU can internally reorder operations as long as observable behaviour remains legal.
2 Per-Thread Execution State
Each thread owns execution state such as its PC register, JVM stack, stack frames, local variables and operand stack.
3 Shared Heap + Objects
Objects and arrays can be shared between threads. Sharing a reference is easy; establishing safe visibility of mutations is the harder problem.
4 Java Memory Model
The JMM defines the legal relationship between reads and writes: program order, synchronisation order, visibility, atomicity and — most importantly — happens-before.
5 Shared Mutable State?
If state is immutable or thread-confined, concurrency reasoning stays simple. If multiple threads mutate it, establish a happens-before edge through synchronized, volatile, locks, atomics, Thread.start() / join() or higher-level concurrency utilities.
6 Observable Outcome
Correct synchronisation gives predictable visibility and ordering. A data race can expose stale values, surprising ordering and executions that look impossible when reasoning only from source-code order.
The key mental model:
GC answers: “Can this memory be reclaimed?”
JMM answers: “Can this thread legally observe that write?”
Those are completely different questions.
