TL;DR

volatile is a lightweight Java concurrency primitive that guarantees visibility and ordering (release/acquire) but not mutual exclusion.
A write to a volatile variable happens-before every subsequent read of that same variable, ensuring the reader sees the write and prior memory actions.
Use volatile for simple flags, safe publication of immutable objects, correct double-checked locking (with volatile), and some lock-free patterns. Do not use it for compound read-modify-write operations — use synchronized or java.util.concurrent.atomic (CAS) instead.
Since Java 5 (JSR-133) volatile semantics are well-defined; Java 9+ adds VarHandle for finer-grained memory ordering (acquire/release/opaque).

Core semantics

Visibility: A volatile write by one thread is visible to subsequent volatile reads by other threads.
Ordering (release/acquire): A volatile write has release semantics (prior writes cannot be reordered after it). A volatile read has acquire semantics (subsequent reads/writes cannot be reordered before it).
Atomicity: Individual reads/writes of volatile variables are atomic for all primitive types (including long/double) and references.
Limitations: volatile does not provide mutual exclusion or atomicity for compound operations (e.g., counter++).

Happens-before & ordering (summary)

Key JMM concepts: program order, monitor order, volatile order, and the happens-before relation. A volatile write happens-before subsequent volatile reads of that variable; happens-before is transitive. These constraints prevent certain reorderings and ensure visibility of memory actions that precede a volatile write.

Practical uses and idioms

Stop flag: single-writer, many-reader boolean flags (worker loop termination).
Safe publication: publish a fully-constructed immutable object by writing its reference to a volatile field.
Double-checked locking: correct when the singleton reference is volatile (prevents seeing a partially constructed object).
Sequence/stamp patterns: version counters used with acquire/release ordering to detect concurrent modification (optimistic reads).
Not suitable: counters using ++ or other read-modify-write sequences — use AtomicInteger, LongAdder, or synchronized blocks.

Examples (condensed)

Stop flag:

private volatile boolean running = true;
void stop() { running = false; }

Safe publication of immutable object:

private static volatile Config cfg;
void set(Config c) { cfg = c; } // publishes fully-initialized cfg
Config get() { return cfg; }

Volatile vs synchronized vs Atomic*

volatile: cheap visibility & ordering, no locking, no atomic compound operations.
synchronized: mutual exclusion + acquire/release; good for complex invariants. JVM optimizations often reduce its cost.
Atomic classes: CAS-based atomic compound operations; suited for lock-free updates and high-concurrency counters.
Choose volatile for simple flags/publication, Atomic* for atomic updates, synchronized for multi-field invariants or critical sections.

Java 9+ VarHandle

VarHandle exposes finer-grained memory modes: getVolatile/setVolatile, getAcquire/setRelease, getOpaque/setOpaque, and CAS operations. Use VarHandle when you need precise, optimized memory-order semantics beyond plain volatile.

JVM ↔ CPU mapping

The JVM implements volatile semantics using platform-specific fences/intrinsics. Hardware models differ (x86 TSO is stronger than ARM/POWER), but the JMM abstracts those differences — program against the JMM, not CPU fences.

Performance considerations & pitfalls

volatile is typically cheaper than synchronized, but still incurs fences and can limit compiler/CPU optimizations.
Avoid excessive volatile usage on hot paths without benchmarking (use JMH).
Beware false sharing: frequently-updated volatile fields on the same cache line cause cache-line bouncing; consider padding or @Contended.
Microbenchmarks can mislead; use JMH and realistic workloads.

Tools for testing & debugging

JCStress — concurrency testing for JMM behaviors.
JMH — accurate microbenchmarking (measure volatile vs synchronized vs atomic).
Static analyzers (FindBugs/SpotBugs) and careful stress tests for race detection.

Best-practices checklist

Use volatile for single-writer/multiple-reader flags, safe publication of immutable objects, and simple release-acquire patterns.
Do NOT use volatile for compound read-modify-write operations or invariants spanning multiple fields.
Prefer Atomic* or synchronized for atomic updates and multi-field invariants.
When building low-level primitives, prefer VarHandle for explicit memory modes (acquire/release/opaque).
Avoid publishing partially constructed objects; ensure construction completes before volatile publication.
Measure performance (JMH) and mitigate false sharing when necessary.

Closing summary

volatile is a powerful, well-specified tool for visibility and ordering (release/acquire) problems. It is ideal for flags, safe publication, and some lock-free patterns, but it is not a replacement for locks or atomic classes for compound operations. Use the JMM as your guide, test with JCStress/JMH, and consider VarHandle for fine-grained memory control.

Java Volatile

Resources for