17370845950

volatile解决线程间变量不可见和指令重排序问题，保证可见性与禁止重排序，但不保证原子性；如volatile int count的count++仍非原子操作，需用AtomicInteger等替代。

volatile 解决什么问题：线程改了值，另一个线程却“看不见”

核心作用就两条：保证可见性 和 禁止指令重排序。它不解决原子性——这点必须先划重点。比如 volatile int count，count++ 仍然是非原子操作，会出错。

典型现象是“死循环卡住”：一个线程把 flag = true，另一个线程还在 while(!flag) 里转圈，永远不退出。这不是代码逻辑错，而是 JVM 和 CPU 的缓存优化导致的——线程各自读写自己的 CPU 缓存，没及时同步到主内存。

• 普通变量：修改只写入本线程工作内存（CPU 缓存），刷新主内存时机不确定
• volatile 变量：写操作强制刷回主内存；读操作强制从主内存加载最新值
• 底层靠 MESI 缓存一致性协议 + 总线嗅探实现，不是靠锁，所以轻量

什么时候必须用 volatile：状态标志、双重检查单例

适用场景非常明确，不是所有共享变量都该加 volatile。滥用反而掩盖真正需要同步的地方。

• 状态标志位：如 volatile boolean isRunning、volatile boolean shutdownRequested，只做开关控制，无复合操作
• 双重检查单例（DCL）中的 instance 引用：防止对象构造未完成就被其他线程看到（避免“半初始化”对象）
• 作为 happens-before 的锚点：配合其他操作建立内存可见性顺序，比如在写 volatile 前写普通变量，能保证该普通变量对后续读该 volatile 的线程可见

反例：不要用它保护计数器、累加器、集合操作等——这些必须用 AtomicInteger 或 synchronized。

为什么 volatile++ 不行：原子性缺失的真实代价

volatile 保证的是“单次读或单次写”的原子性（如 boolean、int 赋值），但 count++ 是三步：read → modify → write，中间可能被其他线程打断。

int count = 0; // 非 volatile
// 线程 A 执行 count++
// 1. 读 count = 0
// 2. 计算 0 + 1 = 1
// 3. 写回 count = 1

// 线程 B 同时执行 count++
// 1. 读 count = 0（此时 A 还没写回）
// 2. 计算 0 + 1 = 1
// 3. 写回 count = 1 → 覆盖 A 的结果

// 最终 count = 1，而非预期的 2

• 即使加了 volatile，上面三步仍可被交叉执行
• 想安全累加，用 AtomicInteger.incrementAndGet()
• 想保护一段逻辑，用 synchronized 或 ReentrantLock

容易忽略的坑：没有 happens-before，volatile 也救不了你

volatile 的可见性不是“全局广播”，它只对**该变量本身**生效。如果还有其他非 volatile 变量依赖它的状态，顺序没约束，照样可能出错。

例如：

private volatile boolean ready = false;
private int data = 0;

// 线程 A
data = 42;           // 普通写
ready = true;        // volatile 写 → 触发 happens-before 关系

// 线程 B
if (ready) {         // volatile 读
    System.out.println(data); // 此处能安全看到 data == 42
}

• 关键在 ready = true 和 data = 42 的先后顺序——JVM 保证前者 happens-before 后者，才让线程 B 读到 data 的新值
• 但如果线程 A 先写 ready = true，再写 data = 42，线程 B 就可能读到 ready == true 但 data == 0
• 所以 volatile 必须和正确的执行顺序配合，不能只靠“加了关键字就万事大吉”

最常被低估的，是它只管“这个变量”，不管“这个变量周围的代码”。一旦涉及多个变量协作或复杂状态流转，就得上更重的同步机制。