volatile Keyword

JavaSeniorjava

The Question

What is the volatile keyword in Java?

What a Strong Answer Covers

• reads/writes from main memory not cache
• ensures visibility across threads
• prevents caching
• not suitable for compound operations like count++
• use AtomicInteger for atomicity

Senior-Level Answer

The volatile keyword in Java is a field modifier that guarantees visibility and ordering guarantees for a variable across multiple threads. Without volatile, each thread may cache a variable's value in its CPU register or L1/L2 cache, meaning writes by one thread are not necessarily visible to other threads reading the same variable.

When a variable is declared volatile, the JVM ensures two things: first, every read of that variable goes directly to main memory rather than a thread-local cache; second, every write to that variable is flushed to main memory immediately. This eliminates the stale-read problem in multi-threaded programs.

volatile also provides a happens-before guarantee: all writes that happened before a volatile write are visible to any thread that reads that volatile variable afterward. This is a weaker guarantee than synchronization — it does not provide atomicity for compound operations. For example, volatile int counter does not make counter++ thread-safe because that operation involves a read, increment, and write — three distinct steps.

The canonical use case for volatile is a boolean status flag: a background thread sets running = false and the worker thread's loop condition checks while (running). Without volatile, the JIT compiler may hoist the read out of the loop entirely, and the worker never sees the update.

volatile is not a replacement for synchronized or Lock. It is appropriate when one thread writes and others only read, or when writes are independent (not derived from the current value). For counters, accumulators, or check-then-act patterns, prefer AtomicInteger or explicit synchronization.

What Separates a 2/3 from a 3/3

Common Mistakes

• Claiming volatile makes compound operations like i++ thread-safe — it does not guarantee atomicity.
• Confusing volatile with synchronized — volatile provides no mutual exclusion or atomicity.
• Not knowing the happens-before relationship volatile establishes, reducing the answer to just 'forces main memory reads'.

Follow-Up Questions

• Why is volatile int counter still not thread-safe for a counter incremented by multiple threads? — The increment is a read-modify-write compound operation; two threads can both read the same stale value before either writes back.
• What is the happens-before relationship and how does volatile establish one? — A happens-before edge means all actions before a volatile write are visible to any thread that subsequently reads that volatile variable.
• When would you choose volatile over AtomicInteger? — volatile suits simple flags or references where one thread writes and others only read. AtomicInteger is needed for compare-and-swap or increment operations.

Related Questions

• JVM vs JRE vs JDK
• Java Platform Independence
• How JVM Works
• Main Features of Java
• public static void main