Understanding Java volatile: Memory Visibility, Ordering, and Interview Insights

In Java interview contexts, interviewers often probe candidates' understanding of concurrency using the volatile keyword as a starting point, which can lead to discussions about the Java Memory Model (JMM), visibility, ordering, atomicity, and related JVM and operating‑system concepts.

Interviewer: How well do you understand Java concurrency? Explain the volatile keyword.

Variables declared volatile have two main properties:

They guarantee memory visibility across threads.

They prohibit certain instruction reorderings.

Interviewer: What are memory visibility and reordering?

The Java Virtual Machine specification defines a Java Memory Model (JMM) that abstracts away hardware and OS memory‑access differences, ensuring consistent behavior across platforms. In JMM, all variables reside in main memory, while each thread has its own working memory (similar to CPU registers or caches). Threads read from main memory into working memory, operate on the local copy, and write back to main memory.

When multiple threads access a shared variable without proper synchronization, cache‑inconsistency problems can arise, as illustrated by the following example:

i = i + 1;

Assume i starts at 0. With a single thread the result is 1, but with two threads the final value may still be 1 because each thread may read the stale value, increment it, and write back the same result.

Interviewer: Explain the three JMM characteristics.

1. Atomicity : Simple reads and writes of primitive types are atomic, but compound actions (e.g., i++ ) consist of multiple steps (read, modify, write) and are not atomic without additional synchronization such as synchronized or Lock .

2. Visibility : A volatile variable forces a write to be flushed to main memory and a subsequent read to fetch the latest value from main memory, guaranteeing that other threads see the most recent update.

3. Ordering : The JMM allows the compiler and CPU to reorder instructions as long as the as‑if‑serial semantics are preserved for a single thread. volatile prevents reordering of operations that appear before and after the volatile access.

Interviewer: How does volatile satisfy the three concurrency properties?

Volatile enforces the visibility and ordering rules via the "volatile variable rule" of the happens‑before relationship: a write to a volatile field happens‑before any subsequent read of that field. Combined with program‑order and transitivity, this ensures the intended ordering of operations.

Interviewer: Can volatile guarantee atomicity?

No. While reads and writes of a single volatile variable are atomic, compound actions such as volatileInt++ are not. A classic demonstration uses multiple threads incrementing a volatile counter, which often yields a result smaller than the expected total because each increment is a read‑modify‑write sequence.

public class Test {
    public volatile int inc = 0;
    public void increase() { inc++; }
    public static void main(String[] args) throws Exception {
        final Test test = new Test();
        for (int i = 0; i < 10; i++) {
            new Thread(() -> {
                for (int j = 0; j < 1000; j++) test.increase();
            }).start();
        }
        while (Thread.activeCount() > 1) Thread.yield();
        System.out.println(test.inc);
    }
}

To achieve atomicity, one must use synchronized , Lock , or classes from java.util.concurrent.atomic .

Interviewer: What is the low‑level implementation of volatile?

Compiling volatile accesses adds a lock prefix to the generated assembly, acting as a memory barrier that prevents reordering, flushes the CPU cache to memory, and invalidates other CPUs' caches, making the write immediately visible to other threads.

Interviewer: Where would you use volatile? Give two examples.

1. State flags (e.g., a volatile boolean flag that signals another thread to proceed).

int a = 0;
volatile boolean flag = false;

public void write() {
    a = 2;      // 1
    flag = true; // 2
}

public void multiply() {
    if (flag) { // 3
        int ret = a * a; // 4
    }
}

2. Double‑checked locking for lazy‑initialized singletons.

class Singleton {
    private static volatile Singleton instance = null;
    private Singleton() {}
    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

In both cases, volatile ensures that updates are promptly visible to other threads while incurring less overhead than full synchronization.

(End of interview)