What does the volatile keyword do in Java, and what problem does it solve?

## The problem: visibility A running Java program may have multiple **threads** (independent paths of execution) on a multi-core CPU. For speed, each CPU core can cache values in registers or local cache, and the Java compiler/JIT may keep a field in a register and reorder instructions. The consequence: when thread A writes a field, thread B running on another core might keep reading an old (stale) copy and never see A's update. This is the **visibility problem**, and it is distinct from a value being computed wrong — the value is fine, it just isn't *propagated*. The canonical bug: ```java boolean running = true; // NOT volatile // thread 1 (worker): while (running) { doWork(); } // thread 2 later: running = false; // worker may NEVER see this and loops forever ``` The JIT is allowed to hoist `running` into a register because, within thread 1's view, nothing changes it, so the loop can spin forever. ## What volatile guarantees Declaring the field `volatile boolean running` provides three guarantees: 1. **Visibility.** A read of a volatile field always returns the *latest* value written by any thread. The value is never served from a stale thread-local cache. 2. **Ordering / happens-before.** A write to a volatile field *happens-before* every subsequent read of that same field. Concretely: everything a thread wrote (volatile *or* plain) *before* the volatile write becomes visible to a thread that later *reads* the volatile field. This is called **piggybacking**: you can publish ordinary data by writing one volatile flag last. 3. **No reordering across the access.** A volatile write has *release* semantics (no earlier memory operation can move after it); a volatile read has *acquire* semantics (no later memory operation can move before it). The compiler and CPU insert memory barriers (fences) to enforce this. The phrase "volatile means the variable is not cached" is a *simplification*. The real mechanism is the acquire/release **memory barriers**; on most hardware a volatile read is nearly free and a volatile write costs a fence. Thinking purely in "no caching" terms misleads on the ordering guarantees. ## What volatile does NOT give you: atomicity Visibility is not the same as **atomicity** (an operation completing as one indivisible step). A **compound** operation — read-modify-write — is still a race even on a volatile field: ```java volatile int count; count++; // really: read count, add 1, write count — three steps ``` Two threads can both read the same value, both add one, and both write it back, losing an increment. volatile fixes nothing here because each individual read and write is fresh, but the *sequence* isn't indivisible. For atomic counters use `AtomicInteger` (lock-free compare-and-swap) or a `synchronized` block. The one bonus: volatile *does* make reads/writes of 64-bit `long` and `double` atomic — without volatile, the JLS permits the JVM to split a 64-bit write into two 32-bit halves, so a reader could see a torn value; volatile (or any synchronization) forbids that tearing. ## Edge case: volatile arrays `volatile int[] arr` makes the **reference** volatile — reassigning `arr` is visible. It does *not* make element writes (`arr[3] = 5`) visible; the volatile applies to the array variable, not its slots. For per-element volatile semantics use `AtomicIntegerArray` or `VarHandle`. ## When to use it Use volatile for a single field that is written by one (or few) threads and read by many, where you need only visibility/ordering and not compound atomicity: status flags, a `done`/`shutdown` boolean, a cached reference published once, or the guard field of the double-checked-locking idiom. When you need to *also* coordinate multiple fields atomically, reach for a lock or an atomic/concurrent class instead.