What Locks Guarantee#

A lock provides two properties that matter when threads share mutable state:

1. Mutual exclusion: only the thread holding the lock can execute the protected critical section.
2. Visibility: changes made before a thread releases a lock become visible to a thread that subsequently acquires the same lock.

Because a lock protects an entire critical section, it can preserve invariants involving multiple fields or multiple operations.

volatile does not create a critical section. Multiple threads can still read and write the field concurrently. Its role is to establish communication between those threads.

What volatile Guarantees#

Declaring a field volatile gives it two central guarantees under the Java Memory Model (JMM).

1
class SharedState {
2
    private int result;
3
    private volatile boolean ready;
4

5
    void produce() {
6
        result = 42;
7
        ready = true;
8
    }
9

10
    void consume() {
11
        if (ready) {
12
            System.out.println(result); // guaranteed to see 42
13
        }
14
    }
15
}

1
int value = 0;
2
boolean ready = false;
3

4
value = 42;
5
ready = true;

Why Reordering Is Usually Safe#

Optimizers preserve data dependencies. Consider this code:

1
double pi = 3.14;        // A
2
double radius = 1.0;     // B
3
double area = pi * radius * radius; // C

Operation C depends on A and B, so it cannot be evaluated before their values are available. A and B do not depend on each other, so an optimizer may execute them in either order.

This freedom improves instruction-level parallelism and is invisible to the executing thread. It becomes important when another thread observes intermediate shared state. Java therefore requires programs to establish happens-before relationships through constructs such as volatile, locks, thread start and termination, or higher-level concurrency utilities.

Memory Barriers#

A JVM can implement JMM ordering rules with compiler barriers and CPU memory fences. A common conceptual vocabulary describes four barrier relationships:

StoreLoad is generally the strongest and most expensive of these relationships.

Explanations of volatile often use a conservative barrier recipe: ordering ordinary stores before a volatile write, ordering later loads after a volatile read, and using stronger fencing where necessary. Treat that as a model for reasoning, not as a literal instruction sequence emitted by every JVM. On x86, ARM, and other architectures, HotSpot may use different instructions or no explicit fence for some operations because each processor already guarantees certain orderings.

The portable rule is the JMM contract: volatile accesses must produce the specified happens-before behavior regardless of the machine running the program.

What volatile Does Not Guarantee#

volatile does not make a compound action atomic.

1
class Counter {
2
    private volatile int count;
3

4
    void increment() {
5
        count++;
6
    }
7
}

Although each read and write of count is atomic and visible, count++ contains three logical steps:

1. Read count.
2. Add one.
3. Write the result.

Two threads can read the same old value and both write the same new value, losing one increment. Use AtomicInteger or a lock instead:

1
private final AtomicInteger count = new AtomicInteger();
2

3
void increment() {
4
    count.incrementAndGet();
5
}

The same warning applies to check-then-act logic and invariants spanning multiple fields. Visibility alone cannot prevent other threads from changing state between steps.

Good Uses for volatile#

volatile works best when one write can independently replace the entire state being communicated.

1
class Worker implements Runnable {
2
    private volatile boolean running = true;
3

4
    void stop() {
5
        running = false;
6
    }
7

8
    @Override
9
    public void run() {
10
        while (running) {
11
            doWork();
12
        }
13
    }
14
}

1
record Configuration(String endpoint, int timeoutMillis) {}
2

3
class ConfigurationStore {
4
    private volatile Configuration current =
5
        new Configuration("https://example.com", 1_000);
6

7
    Configuration get() {
8
        return current;
9
    }
10

11
    void update(Configuration next) {
12
        current = next;
13
    }
14
}

When to Use Something Else#

Choose the tool based on the operation rather than on a vague idea that one primitive is faster:

Performance#

A volatile access is usually cheaper than acquiring a contended lock because it does not provide mutual exclusion or park waiting threads. It is not free: it restricts compiler and processor optimizations and can generate cache-coherence traffic. The exact cost depends on the hardware, JVM, contention pattern, and surrounding code.

Performance is therefore secondary to semantics. If an operation requires atomicity, replacing a lock with volatile is not an optimization; it is a correctness bug.

Summary#

volatile is a communication mechanism for shared fields:

• A volatile write happens-before a subsequent read of the same field.
• That relationship makes earlier writes visible to the reading thread.
• The JVM prevents reorderings that would violate this guarantee.
• Volatile reads and writes do not make compound operations such as count++ atomic.
• Exact barriers and assembly instructions are JVM- and architecture-dependent.

Use volatile for independently replaceable state such as flags and immutable snapshots. Use atomic classes or locks when correctness depends on a read-modify-write sequence or an invariant involving multiple pieces of state.

Practical Decision Guide#

1
private volatile boolean running = true;
2

3
void stop() {
4
    running = false;
5
}
6

7
void runLoop() {
8
    while (running) {
9
        doWork();
10
    }
11
}

1
private volatile int progressPercent;
2

3
void reportProgress(int progress) {
4
    progressPercent = progress;
5
}

1
public final class Singleton {
2
    private static volatile Singleton instance;
3

4
    private Singleton() {}
5

6
    public static Singleton getInstance() {
7
        Singleton result = instance;
8
        if (result == null) {
9
            synchronized (Singleton.class) {
10
                result = instance;
11
                if (result == null) {
12
                    result = new Singleton();
13
                    instance = result;
14
                }
15
            }
16
        }
17
        return result;
18
    }
19
}