17370845950

volatile 通过强制每次读从主内存加载、每次写立即刷回主内存来保证可见性，并借助内存屏障禁止相关指令重排序，但不保证原子性和互斥。

volatile 为什么能保证可见性

因为 JVM 对 volatile 字段的每次读操作都会从主内存重新加载，每次写操作都会立即刷回主内存，绕过线程本地缓存（如 CPU cache 或寄存器缓存）。普通变量可能被编译器优化成寄存器副本，或被 CPU 缓存在 core local cache 中，导致其他线程看不到最新值。

实操注意点：

• volatile 不是锁，它不阻止指令重排，也不提供原子性（比如 i++ 仍需同步）
• 仅对单个变量读/写有效；若涉及多个 volatile 变量的复合逻辑（如先写 A 再写 B），不能靠 volatile 保证它们之间的顺序可见
• JDK 1.5+ 的内存模型才正式定义了 volatile 的语义，老版本行为不可靠

volatile 如何禁止指令重排序

JVM 和 CPU 都可能对指令重排序以提升性能，但会在 volatile 读写前后插入内存屏障（Memory Barrier）：写 volatile 会加 StoreStore + StoreLoad 屏障，读 volatile 会加 LoadLoad + LoadStore 屏障。这限制了编译器和处理器对相关指令的乱序执行。

典型场景是双重检查锁单例：

public class Singleton {
    private static volatile Singleton instance;
    private Singleton() {}
    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton(); // ① 分配内存 → ② 初始化 → ③ 赋值给 instance
                }
            }
        }
        return instance;
    }
}

没有 volatile 时，JVM 可能将步骤 ② 和 ③ 重排序，导致其他线程拿到未初始化完成的对象引用。

volatile 不能替代 synchronized 的地方

常见误解是“volatile 解决了线程安全问题”，其实它只解决可见性和部分有序性，不解决原子性与互斥。

以下情况必须用 synchronized 或 java.util.concurrent 工具：

• count++ 这类非原子操作：读、改、写三步，volatile 只能保证每一步的读写可见，无法防止中间被其他线程打断
• 需要临界区保护的多变量协同（如银行转账中两个账户余额同时更新）
• 等待/通知机制（wait()/notify() 必须在 synchronized 块中）
• volatile boolean flag = false; 若多个线程反复读写该 flag，且依赖其变化做状态流转，仍可能因缺少 happens-before 关系导致逻辑错乱

面试常踩的坑：happens-before 与 volatile 的关系

很多人背下“volatile 写 happens-before 后续的 volatile 读”，但忽略前提：必须是**同一个 volatile 变量**，且读操作发生在写操作之后（时间上或逻辑上）。不是所有读都自动建立 happens-before。

例如：

volatile int a = 0;
int b = 1;

// 线程1：
a = 1; // volatile write
b = 2; // 普通写

// 线程2：
if (a == 1) { // volatile read
    System.out.println(b); // 这里不一定看到 b == 2！
}

虽然 a = 1 happens-before a == 1，但 b = 2 和 System.out.println(b) 之间没有 happens-before 关系，所以 b 的值不可见。

真正容易被忽略的是：volatile 的语义完全依赖 JVM 内存模型实现，而不同平台（x86/ARM）的底层内存序差异会让某些看似“应该生效”的重排在特定硬件上意外通过——别靠猜测，有并发逻辑就该用明确的同步机制。