volatile Keyword in Java

In a multithreaded Java program, each thread can, for performance reasons, keep its own cached copy of a variable's value — in a CPU register or a core-local cache — rather than reading it fresh from main memory on every access. This is normally invisible and harmless for single-threaded code, but it creates a serious correctness problem once multiple threads share a variable: one thread can update a value while another thread keeps reading its own stale, cached copy indefinitely, never seeing the update at all.

The volatile keyword exists to solve exactly this "visibility" problem. It is one of the most misunderstood keywords in Java, largely because people assume it does more than it actually does — in particular, many developers wrongly assume it makes operations like incrementing a counter safe across threads, which it does not.

Why it matters

A missing volatile causes one of the hardest bugs to reproduce: a thread that never sees a change made by another thread, often only on certain machines or after the code has been running for a while. The opposite mistake is just as common: adding volatile to a counter and assuming it is now safe. Knowing exactly what the keyword guarantees prevents both.

The Visibility Problem, Concretely

Imagine one thread sets a boolean flag to signal another thread to stop working, in a loop like while (!stop) { doWork(); }. Without volatile, the JVM and the underlying hardware are both allowed to assume the worker thread is the only one that ever changes "stop," so the compiler may keep the value of "stop" cached in a register instead of re-reading it from main memory on every loop iteration. If another thread sets "stop = true", the worker thread may never notice — it keeps looping forever, reading its own stale cached copy.

What volatile Guarantees

Declaring a field volatile gives it two specific guarantees. First, visibility: every read of a volatile variable is guaranteed to see the most recently completed write to it from any thread — the JVM forces reads and writes to interact directly with main memory (conceptually) rather than a thread-local cache. Second, ordering: the compiler and processor are prevented from reordering instructions across a volatile read or write, which prevents certain classes of subtle reordering bugs in concurrent code.

What volatile Does NOT Guarantee: Atomicity

This is the critical limitation. volatile makes individual reads and individual writes visible correctly, but it does nothing to make compound (multi-step) operations atomic. An operation like counter++ is actually three separate steps — read the current value, add one to it, write the new value back — and two threads can each perform the "read" step before either performs the "write" step, silently losing an increment. Marking the counter volatile does not fix this, because visibility of each individual read/write is not the same thing as making the whole read-modify-write sequence indivisible. For that, you need either a synchronized block/method, or an atomic class such as AtomicInteger, which performs the entire read-modify-write as one indivisible hardware-backed operation.

Examples

public class VolatileFlagDemo {
    private static volatile boolean stop = false;

    public static void main(String[] args) throws InterruptedException {
        Thread worker = new Thread(() -> {
            int iterations = 0;
            while (!stop) {
                iterations++; // busy work; "stop" is re-checked from main memory each time
            }
            System.out.println("Worker stopped after noticing the flag, iterations=" + (iterations > 0));
        });

        worker.start();
        Thread.sleep(50);   // let the worker run briefly
        stop = true;        // visible to the worker thread immediately because "stop" is volatile
        worker.join();
        System.out.println("Main thread confirmed worker has exited");
    }
}

Worker stopped after noticing the flag, iterations=true
Main thread confirmed worker has exited

import java.util.concurrent.atomic.AtomicInteger;

public class VolatileCounterPitfall {
    private static volatile int unsafeCounter = 0;   // visibility only, NOT atomic
    private static final AtomicInteger safeCounter = new AtomicInteger(0); // atomic read-modify-write

    public static void main(String[] args) throws InterruptedException {
        Runnable incrementBoth = () -> {
            for (int i = 0; i < 10000; i++) {
                unsafeCounter++;             // read-modify-write race: increments can be lost
                safeCounter.incrementAndGet(); // indivisible operation: never loses an increment
            }
        };

        Thread t1 = new Thread(incrementBoth);
        Thread t2 = new Thread(incrementBoth);
        t1.start(); t2.start();
        t1.join(); t2.join();

        System.out.println("Expected: 20000");
        System.out.println("unsafeCounter (volatile only): " + unsafeCounter + " (often less than 20000)");
        System.out.println("safeCounter (AtomicInteger): " + safeCounter.get());
    }
}

Expected: 20000
unsafeCounter (volatile only): <some value <= 20000, unreliable>
safeCounter (AtomicInteger): 20000

Exercise

Two threads each add 1 to a shared counter 10,000 times. With a volatile int and counter++, some increments are lost and the total varies between runs. Replace the counter with an AtomicInteger so the program always prints the same total.

Expected output: 20000

public class SafeCounter {
    // TODO: replace this with an AtomicInteger
    private static volatile int counter = 0;

    public static void main(String[] args) throws InterruptedException {
        Runnable task = () -> {
            for (int i = 0; i < 10000; i++) {
                counter++; // TODO: use an atomic increment
            }
        };

        Thread t1 = new Thread(task);
        Thread t2 = new Thread(task);
        t1.start();
        t2.start();
        t1.join();
        t2.join();

        System.out.println(counter); // TODO: print the value of the AtomicInteger
    }
}

import java.util.concurrent.atomic.AtomicInteger;

public class SafeCounter {
    private static final AtomicInteger counter = new AtomicInteger(0);

    public static void main(String[] args) throws InterruptedException {
        Runnable task = () -> {
            for (int i = 0; i < 10000; i++) {
                counter.incrementAndGet(); // read, add and write as one step
            }
        };

        Thread t1 = new Thread(task);
        Thread t2 = new Thread(task);
        t1.start();
        t2.start();
        t1.join();
        t2.join();

        System.out.println(counter.get()); // 20000
    }
}

Quick quiz

Interview questions