Understanding Java volatile: Principles, Usage, and Best Practices

In multithreaded Java programming, the volatile keyword plays a crucial role in ensuring that shared variables are consistently visible across threads.

1. Volatile Overview : According to the Java Language Specification, declaring a field as volatile guarantees that all threads see the same value, providing a lighter‑weight alternative to exclusive locks.

1.2 Lightweight Compared to synchronized : It requires less code, incurs lower runtime overhead, and avoids thread‑context switches.

1.3 Visibility in Multiprocessor Systems : volatile ensures that when one thread updates a variable, other threads can immediately observe the new value.

1.4 Visibility Without Atomicity : While it offers the visibility guarantees of synchronized, it does not provide atomic operations.

1.5 Performance Advantage : When read operations far outnumber writes, volatile can outperform locks.

2. Underlying Principle : Processors cache memory values; a write to a volatile variable triggers a lock‑prefix instruction that flushes the cache line to main memory and invokes a cache‑coherence protocol so other CPUs invalidate stale copies.

3. Conditions for Using volatile :

3.1 The write does not depend on the current value (e.g., cannot be used for thread‑safe counters).

3.2 The variable is not part of a larger invariant.

Example of a non‑thread‑safe class:

@NotThreadSafe
public class NumberRange {
    private int lower, upper;
    public int getLower() { return lower; }
    public int getUpper() { return upper; }
    public void setLower(int value) {
        if (value > upper) {
            throw new IllegalArgumentException(...);
        }
        lower = value;
    }
    public void setUpper(int value) {
        if (value < lower) {
            throw new IllegalArgumentException(...);
        }
        upper = value;
    }
}

Making lower and upper volatile does not make the class thread‑safe because concurrent updates can leave the range inconsistent.

4. Usage Patterns

4.1 State Flag

Typical boolean flag implementation:

volatile boolean shutdownRequested;
...
public void shutdown() {
    shutdownRequested = true;
}
public void doWork() {
    while (!shutdownRequested) {
        // do stuff
    }
}

This avoids the overhead of synchronized blocks for a simple visibility‑only flag.

4.2 One‑time Safe Publication (Double‑Checked Locking)

private volatile static Singleton instance;
public static Singleton getInstance() {
    // first null check
    if (instance == null) {
        synchronized (Singleton.class) {
            // second null check
            if (instance == null) {
                instance = new Singleton(); // instance creation
            }
        }
    }
    return instance;
}

Without volatile, reordering could allow another thread to see a partially constructed instance.

4.3 Independent Observation

Periodically publish sensor readings to a volatile variable so other threads can always read the latest value.

4.4 “volatile bean” Pattern

All fields of a JavaBean are declared volatile, and getters/setters contain no additional constraints, allowing frameworks to store mutable data safely.

4.5 Low‑Cost Read‑Write Lock Strategy

Combine an internal lock for mutations with a volatile field for reads to reduce contention:

@ThreadSafe
public class CheesyCounter {
    // All mutative operations must hold 'this' lock
    @GuardedBy("this") private volatile int value;
    // Read operation – no synchronized, high performance
    public int getValue() {
        return value;
    }
    // Write operation – must be synchronized because ++ is not atomic
    public synchronized int increment() {
        return value++;
    }
}

This pattern leverages volatile for fast reads while using synchronization only for writes.