volatile 关键字：可见性与禁止指令重排

提出问题

在 Java 多线程编程中，一个线程修改了某个变量，其他线程什么时候能看到这个修改？这个问题看似简单，但在 CPU 多级缓存 + 编译器优化的组合下，结果往往出乎意料。volatile 是 Java 提供的最轻量级同步机制，它不涉及锁、不会引起线程阻塞，但能保证变量修改的可见性和有序性。面试官问 volatile 通常不只是想知道"保证可见性，不保证原子性"这种八股式回答，而是想考察：底层怎么实现的？内存屏障插在哪？为什么 DCL 单例必须用它？什么时候该用 volatile 而不是锁？

分析问题

volatile 的语义：可见性 + 有序性

volatile 在 JMM（Java Memory Model）中提供了两个保证：

可见性：当一个线程修改了 volatile 变量，新值会立即被刷回主内存，其他线程读取该变量时，必须从主内存重新加载，而不是从自己的工作缓存中读。这实际上打破了"每个线程有独立工作内存"的 JMM 抽象模型，让 volatile 变量的读写直接穿透到主内存。

有序性：volatile 禁止 JIT 编译器和 CPU 对 volatile 变量相关的读写操作进行指令重排序。具体规则是：

• 对 volatile 变量的写操作，不能与它之前的任意读写操作重排序
• 对 volatile 变量的读操作，不能与它之后的任意读写操作重排序

不保证原子性：count++ 这条语句在字节码层面是三步：读 count → 加 1 → 写回 count。volatile 只保证每一步的可见性，但不保证三步作为一个整体不被中断。两个线程同时执行 count++，即使 count 是 volatile，最终结果仍可能少加一次。

底层实现：内存屏障

volatile 的可见性和有序性在硬件层面通过**内存屏障（Memory Barrier）**实现。JVM 在编译 volatile 读写时，会根据目标 CPU 架构插入不同组合的屏障指令：

volatile 写：
  [StoreStore] → 变量赋值 → [StoreLoad]
  
volatile 读：
  [LoadLoad] → [LoadStore] → 变量读取

四种屏障的语义：

• StoreStore：屏障前的所有普通写操作，必须对屏障后的 volatile 写操作可见
• StoreLoad：屏障前的所有写操作，必须对屏障后的所有读操作可见（这是最重的屏障，x86 下约 10-20 个 CPU 周期）
• LoadLoad：屏障前的所有普通读操作，必须在屏障后的 volatile 读操作之前完成
• LoadStore：屏障前的读操作，必须在屏障后的写操作之前完成

在 x86 架构下，由于 TSO（Total Store Order）内存模型本身有较强的排序保证，只有 StoreLoad 屏障需要实际的 CPU 指令（mfence 或 lock addl），其他三个屏障在 x86 上是空操作。而在 ARM/PowerPC 等弱内存模型架构上，四种屏障都需要插入，这也是为什么 volatile 在不同硬件平台上性能差异显著。

经典应用场景

场景一：状态标志位

public class TaskRunner {
    private volatile boolean running = true;
    
    public void run() {
        while (running) {
            // 执行任务
        }
    }
    
    public void stop() {
        running = false;  // 其他线程通过 stop() 修改后，run() 线程立即可见
    }
}

如果不加 volatile，run() 线程可能永远看不到 running = false 的修改，因为 JIT 可能会将 while(running) 优化成 if(running) while(true)，导致死循环。

场景二：DCL 单例

public class Singleton {
    private static volatile Singleton instance;
    
    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

instance = new Singleton() 在字节码层面包含三步：分配内存 → 调用构造函数 → 将引用指向内存地址。如果不加 volatile，JIT 可能重排为：分配内存 → 将引用指向内存地址 → 调用构造函数（延迟初始化）。此时另一个线程读到 instance != null，直接返回，拿到的对象构造函数还没执行完，访问字段就会读到默认值。

场景三：安全的双重检查

public class ConfigHolder {
    private volatile Config config;
    private volatile boolean initialized;
    
    public void init(Config cfg) {
        if (!initialized) {
            synchronized (this) {
                if (!initialized) {
                    config = cfg;
                    initialized = true;  // volatile 写，保证 config 赋值对读线程可见
                }
            }
        }
    }
    
    public Config getConfig() {
        return config;  // volatile 读，保证读到最新值
    }
}

volatile 与 synchronized 的选择

特性	volatile	synchronized
可见性	✅	✅
有序性	✅（禁止重排）	✅（临界区序列化）
原子性	❌（仅单变量读/写）	✅（临界区内全部）
阻塞	不阻塞	会阻塞
性能	轻量（尤其读操作）	重量（锁竞争）

一句话选型原则：单个变量的状态可见性用 volatile，复合操作或临界区用 synchronized。

总结

• volatile 保证可见性和有序性，不保证原子性——这是最常被问的区分点
• 底层靠内存屏障实现，x86 上只有 StoreLoad 屏障需要实际 CPU 指令
• 三大经典场景：状态标志位、DCL 单例、安全的双重检查
• 面试话术示范：面试官问"volatile 和 synchronized 的选择"，可以从"语义层面"和"性能层面"分层回答——前者说可见性/有序性/原子性的差异，后者说 volatile 读没有锁开销但写操作有 StoreLoad 屏障的代价，再根据场景给出选型建议
• 生产避坑：count++ 这种复合操作即使 volatile 也不安全，必须用 AtomicInteger 或 synchronized；循环内频繁读取 volatile 变量仍然有性能损耗（读操作需要从主内存加载），如果读取频率极高且写极少，可以考虑用 LongAdder

参考：JSR 133 (Java Memory Model) FAQ、JVM 源码 src/hotspot/share/runtime/globals.hpp 中关于 UseStoreStoreBarrier 等参数、Intel 64 and IA-32 Architectures SDM Vol.3A — 内存顺序与屏障