Java Memory Model: interview questions & scenarios

Model answer

Here's the code, trimmed down. A worker spins until main flips a plain boolean:

public class StopFlag {
    static boolean running = true;   // try it with and without volatile

    public static void main(String[] args) throws InterruptedException {
        Thread worker = new Thread(() -> {
            long spins = 0;
            while (running) {
                spins++;             // no method calls in the loop body
            }
            System.out.println("worker stopped after " + spins + " spins");
        });
        worker.setDaemon(true);
        worker.start();

        Thread.sleep(500);
        running = false;
        System.out.println("main: set running = false");

        worker.join(2000);           // watchdog: never wait forever
        System.out.println(worker.isAlive() ? "worker STILL running after 2 s" : "done");
    }
}

Three real runs, then one with volatile boolean running, then one with the JIT switched off (-Xint, interpreter only):

$ java StopFlag.java          (3 runs, same result every time)
main: set running = false
worker STILL running after 2 s

$ java StopFlagVolatile.java
main: set running = false
worker stopped after 1541774902 spins
done

$ java -Xint StopFlag.java
main: set running = false
worker stopped after 166109416 spins
done

That last run is your "it works in the debugger" moment. The bug isn't in the CPU. It's in the JIT compiler. After a few thousand iterations, HotSpot's C2 compiler optimises the hot loop. Nothing in the loop writes running, and nothing in it synchronizes, so the compiler is allowed to read running once and turn the loop into if (running) while (true) spins++;. The worker never looks at memory again.

A debugger, a breakpoint or -Xint keeps the code in the slow interpreter, which re-reads the field every time. So the bug vanishes the moment you go looking for it.

The fix is volatile boolean running (or an AtomicBoolean, or interrupting the thread). A volatile read can't be hoisted or cached, and the write in main happens-before every later read that sees it.

Model answer

The Java Memory Model (JMM) is the contract that answers one question: when one thread writes a variable, which values is another thread allowed to see when it reads it? It lives in JLS chapter 17.4.

Think of a busy restaurant kitchen. The head chef writes "table 7: no nuts" on the board. Without a rule like "always check the board before you plate", a cook might work from what they remember instead. The JMM is that rule, written down so precisely that compilers, CPUs and JVM authors can all agree on it.

Why does Java need it? Because three layers rewrite your code for speed, and none of them think about other threads by default:

Every one of those is invisible inside a single thread. That's the deal: as-if-serial semantics, your thread always sees its own code run in order. Another thread watching from outside gets no such promise unless you use the tools the JMM defines: synchronized, volatile, final, Thread.start()/join() and the java.util.concurrent classes.

The JMM is specified with happens-before, not with caches or barriers. That's on purpose. Java runs on x86, ARM, POWER and RISC-V, and each has different hardware rules. The JMM gives one portable rule; each JVM maps it to its own hardware.