The volatile keyword ensures the visibility of variables and prohibits instruction reordering in a multi-threaded environment. 1. Using volatile can ensure that one thread’s modification of variables is immediately visible to other threads, avoiding inconsistent values caused by CPU cache; 2. volatile prevents instruction reordering through happens-before rules, ensuring that modifications before write operations are visible to subsequent read operations; 3. It is suitable for simple scenarios such as status flags, such as shutdown flags; 4. However, it does not guarantee the atomicity of composite operations, such as count, still requires AtomicInteger or lock mechanism; 5. volatile cannot replace the synchronization mechanism to achieve complete thread safety. Therefore, volatile is suitable for shared variables that are single write thread, multi-read thread and do not require atomicity, but is not suitable for scenarios where frequent concurrent modifications or require atomic operations.

The volatile keyword in Java plays a specific and important role in multi-threaded programming. It's not a silver bullet for thread safety, but it solves a particular problem: visibility of shared variables across threads .

When multiple threads access the same variable, especially when one or more threads modify it, you can run into situations where one thread doesn't see the most recent value written by another. This happens due to optimizations like CPU caching and instruction reordering. The volatile keyword helps address this.

What volatile Guarantees

Adding volatile to a variable declaration ensures two key guarantees:

1. Visibility : Changes to a volatile variable are always visible to other threads. When one thread writes to a volatile variable, the JVM ensures that the new value is immediately written back to main memory, and when another thread reads that variable, it reads the latest value from main memory—not from a local CPU cache.

2. Prevention of Instruction Reordering : The JVM and CPU may reorder instructions for performance, but this can break correctness in concurrent code. volatile imposes a happens-before relationship, meaning:

   
   • All writes before a write to a volatile variable are guaranteed to be visible before the write.
   • All reads after a read of a volatile variable are guaranteed to see the effects of that read and earlier writes.

This makes volatile useful in signaling flags or state indicators.

Example: Using volatile as a Shutdown Flag

 public class Worker implements Runnable {
    private volatile boolean running = true;

    public void shutdown() {
        running = false;
    }

    @Override
    public void run() {
        while (running) {
            // do work
        }
        System.out.println("Worker stopped.");
    }
}

Without volatile , the thread running run() might cache the value of running in a register and never see the update from another thread calling shutdown() , leading to an infinite loop.

With volatile , the thread checks the main memory value each time, so it sees the change immediately (or at least very soon, depending on time).

What volatile Does Not Guarantee

It's cruel to understand what volatile doesn't do:

• ? Atomicity : Reading or writing a volatile variable is atomic for simple types (like boolean , int , references), but compound operations (eg, count ) are not. That expression involves read, modify, write — and another thread could change the value in between.

  Example:

   volatile int counter = 0;
  counter ; // Not atomic!

  This can still result in lost updates. Use AtomicInteger instead for such cases.

• ? Full Thread Safety : Making a variable volatile doesn't make a class thread-safe. If multiple threads modify related state, you still need synchronization via synchronized , ReentrantLock , or atomic classes.

---

When to Use volatile

Use volatile when:

• ? You have a shared variable that is read by multiple threads and written by one (or occasionally more, if atomicity isn't required).
• ? You're using it as a status flag (eg, shutdownRequested , initialized , ready ).
• ? You need to avoid stale values due to caching.
• ? You want to ensure ordering of actions around reads/writes to that variable.

Avoid volatile when:

• ? You're performing compound operations (read-modify-write).
• ? Multiple threads are updating the variable frequently and correctness depends on atomicity.

---

Summary

• volatile ensures visibility and prevents certain compiler/CPU reorderings.
• It's lightweight compared to synchronized blocks.
• It's not a replacement for proper synchronization when atomicity is required.
• Best used for simple flags or state indicators in concurrent programs.

Basically, volatile is a subtle but powerful tool—use it when you need threads to see the latest value of a variable, but don't expect it to handle everything concurrency throws at you.

The above is the detailed content of The Role of the `volatile` Keyword in Java Concurrency. For more information, please follow other related articles on the PHP Chinese website!