Understanding Java volatile: Visibility, Ordering, and Usage in Concurrent Programming

1. Introduction

volatile is a lightweight synchronization mechanism provided by Java. Java has two built‑in synchronization mechanisms: synchronized blocks/methods and volatile variables. Compared with synchronized (a heavyweight lock), volatile is lighter because it does not trigger thread context switches, but its synchronization guarantees are weaker and it is easier to misuse.

2. Three Basic Concepts of Concurrent Programming

(1) Atomicity

Definition: an operation or a group of operations must either execute completely without interruption or not execute at all.

Atomicity means that at any moment only one thread can operate on an atomic variable. For example, a simple assignment a = 1 is atomic, while a++ or a += 1 is not.

Java atomic operations include:

Reading and writing of primitive types (numeric assignment only).

Assignment of reference variables.

All operations of classes in java.util.concurrent.atomic.*.

(2) Visibility

Definition: when multiple threads access the same variable, a change made by one thread becomes immediately visible to the others.

volatile guarantees visibility by invalidating a thread’s local cache; after a write, the new value is flushed to main memory and subsequent reads fetch it from main memory. synchronized and Lock also provide visibility.

(3) Ordering

Definition: program execution follows the order written in the code.

In the Java Memory Model, operations appear ordered within a single thread but may be reordered across threads. volatile provides a limited ordering guarantee, preventing certain re‑orderings that could break the double‑checked locking pattern.

3. Mutual Exclusion and Visibility of Locks

Locks provide mutual exclusion (only one thread can hold a particular lock at a time) and visibility (changes made before releasing a lock become visible to the thread that subsequently acquires the lock).

4. Java Memory Model (JMM) and Shared Variable Visibility

JMM defines an abstract relationship between threads and main memory. Shared variables reside in main memory, while each thread has a private working memory that holds a copy of the variables it uses. Threads must read/write variables through their working memory, not directly to main memory.

Without proper synchronization, a write performed in one thread’s working memory may not be visible to another thread, leading to inconsistency. volatile offers a lightweight alternative to synchronized for ensuring visibility.

5. Characteristics of volatile Variables

(1) Guarantees visibility but not atomicity

a. Writing a volatile variable forces the thread’s local copy to be flushed to main memory.

b. The write invalidates caches of other threads.

(2) Prohibits instruction reordering

Reordering is allowed for performance as long as data dependencies are respected and single‑thread semantics are preserved. volatile inserts memory barriers that ensure all preceding operations complete before the volatile access and no subsequent operation moves before it.

6. Scenarios Where volatile Is Not Suitable

(1) Not suitable for compound operations

Operations like inc++ consist of read‑modify‑write steps and are not atomic, so volatile cannot guarantee correct results.

(2) Solutions

Use synchronized, Lock, or atomic classes from java.util.concurrent (which rely on CAS loops) to achieve atomicity.

7. Underlying Mechanism of volatile

At the JVM level, volatile is implemented with memory barriers (often a LOCK prefix instruction). The barrier provides three functions:

Prevents reordering of instructions across the barrier.

Forces cached modifications to be written to main memory immediately.

Invalidates corresponding cache lines in other CPUs on a write.

8. Why volatile Is Needed in Double‑Checked Locking Singleton

Without volatile, the instance creation steps (allocate memory, construct object, assign reference) may be reordered, causing another thread to see a non‑null reference to an incompletely constructed object. Declaring the instance variable as volatile prevents this reordering.