多线程读写volatile变量：哪些操作有保证，哪些无保证？

Awesome question—volatile is one of those Java concurrency primitives that feels simple when you’re dealing with just two threads, but things get way more nuanced once multiple threads are reading and writing. Let’s break down exactly what guarantees you get, and what you definitely don’t, when using volatile in a multi-threaded scenario.

• Full Visibility of Writes: Any write to a volatile variable by one thread is immediately flushed to main memory, and subsequent reads by any other thread will pull directly from main memory (not their local cache). So if Thread A writes x = 10, every thread that reads x after that write will see the value 10—no stale cache values hanging around.
• Instruction Reordering Prevention: The JVM and CPU won’t reorder operations around volatile reads/writes, thanks to the happens-before rule. For example:
  • All non-volatile operations that happen before a volatile write will complete before the volatile write is committed to main memory.
  • All non-volatile operations that happen after a volatile read won’t execute before the volatile read pulls the latest value from main memory.
    This is critical for things like initializing a resource and then setting a volatile flag—other threads that see the flag as set will know the resource is fully initialized.
• Atomicity of Single Reads/Writes: Individual read or write operations on a single volatile variable are atomic. For example, volatile int x; x = 42; or int y = x; can’t be split halfway—you’ll never read a partial value (like half of a 64-bit long, though in modern JVMs even non-volatile longs are atomic, but volatile guarantees it explicitly).

• Atomicity of Compound Operations: Volatile doesn’t make compound operations (like x++, x += 5, or checking-and-setting) atomic. These operations are actually three separate steps: read the current value, modify it, write it back. Multiple threads can interfere here—for example, if two threads read x = 0 at the same time, both increment to 1, and both write back, you’ll end up with x = 1 instead of the expected 2. For these cases, use AtomicInteger/AtomicLong or synchronized blocks.
• Consistency Across Multiple Variables: Volatile only ensures visibility and ordering for the single variable it’s applied to. If you have a volatile flag and a non-volatile data variable, Thread A writing data then flag = true doesn’t guarantee that Thread B, after reading flag = true, will see the updated data. You’d need to make data volatile too, or use a synchronized block to ensure cross-variable consistency.
• Mutual Exclusion: Volatile doesn’t provide any locking or mutual exclusion. Multiple threads can read and write the volatile variable at the exact same time—there’s no blocking or queuing of access. If you need to protect a critical section of code (where only one thread can execute at a time), volatile won’t help; you need synchronized, ReentrantLock, or similar tools.
• Fixing All Race Conditions: It’s a common misconception that volatile solves all concurrency issues. It only addresses race conditions caused by visibility or instruction reordering. Race conditions caused by missing atomicity for compound operations or lack of mutual exclusion are still fully possible with volatile variables.

内容的提问来源于stack exchange，提问作者Nick T.