Why a Volatile Boolean Won’t Stop a Java Thread Loop – and What Actually Works

Interview Question

A thread runs an infinite loop controlled by a boolean flag that is initially true. After some time the main thread sets the flag to false. The question is whether the child thread can exit if the flag is not declared volatile.

Principle

The volatile keyword addresses two core problems: visibility and instruction‑reordering. Visibility means the CPU cache must be invalidated so that a thread reads the latest value from main memory. Reordering prevention on x86 is implemented as a store‑load memory barrier (the “happen‑before” rule). The underlying mechanism uses the esp register. Without volatile, the cached value may never be refreshed, so the loop may never notice the change.

Solution

Declare the flag as volatile to force a write‑through to main memory and guarantee that other threads see the updated value, allowing the loop to terminate. Even inserting a System.out.println inside the loop works because the method is synchronized, which flushes the working memory. A more robust alternative is to use AtomicBoolean or AtomicReference, which not only ensure visibility but also provide atomic compare‑and‑set operations.