Why do we use the volatile keyword?

In Java programming, the use of the volatile keyword is crucial because it provides a lightweight synchronization mechanism that ensures variable visibility and prevents instruction reordering in multi-threaded environments.

1. Ensure Variable Visibility

Without the volatile keyword, threads may cache variables in their local memory. Consequently, when one thread updates a variable, other threads might not observe this change. When a variable is declared as volatile, it instructs the JVM and compiler not to cache the variable; instead, every access must read from main memory, and every modification must be written back to main memory immediately. This guarantees that changes made to the variable in one thread are immediately visible to other threads.

Example:

Suppose there is a flag flag controlling whether a thread continues execution. If flag is not declared as volatile, even if the main thread updates flag to false (stopping the controlling thread), the working thread might still see the old value of flag as true due to thread-local caching, causing the program to execute incorrectly.

java
class SharedObject {
    private boolean flag = false;

    public void changeFlag() {
        this.flag = true;
    }

    public void execute() {
        while (!flag) {
            // Waiting for flag to become true to execute certain operations
        }
        // Execute necessary tasks
    }
}

2. Prevent Instruction Reordering

In the Java Memory Model (JMM), compilers and processors often reorder instructions to improve efficiency. During reordering, the execution order of instructions may change, but the result remains consistent for single-threaded execution. However, this reordering can compromise the correctness of multi-threaded programs. Declaring a variable as volatile prevents the JVM and compiler from reordering operations related to these variables, thereby ensuring the correctness and consistency of the program in multi-threaded environments.

Example:

Consider a delayed initialization scenario for a singleton pattern using Double-Checked Locking. If the reference to the singleton object is not declared as volatile, it is possible to obtain an incompletely constructed object in some cases. This occurs because the object construction process (allocating memory, initializing the object, and setting the reference to the memory location) may be reordered, allowing other threads to check the reference for non-null and assume the object is initialized, even if it is not fully constructed.

java
class Singleton {
    private static volatile Singleton instance;

    private Singleton() {}

    public static Singleton getInstance() {
        if (instance == null) { // First check
            synchronized (Singleton.class) {
                if (instance == null) { // Second check
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

Finally, using the volatile keyword ensures the safety and correctness of programs in multi-threaded environments. Although it does not address all concurrency issues, such as atomicity guarantees, it is a simple and effective solution in appropriate scenarios.