一、引言

在 Java 并发编程中，我们经常会能看到volatile 的身影，提到volatile往往就离不开讲操作系统内存重排序的概念。

今天我们结合具体 case 讲一讲volatile以及到底什么是内存重排。

二、Java volatile关键字详解

2.1 什么是 volatile？

volatile 是 Java 提供的一个变量修饰符，用于告诉 JVM：

“这个变量可能会被多个线程同时访问，请确保它的值对所有线程都是最新、可见的，并且不要对它的读写操作进行重排序。”

2.2 volatile的三大特性

2.3 可见性：解决“缓存不一致”问题

现代 CPU 为了提高效率，每个线程都有自己的工作内存（高速缓存），变量副本可能不会立即写回主内存。

public class VolatileVisibility {
    private boolean flag = false; //  没有 volatile

    public void writer() {
        flag = true; // 线程A修改
    }

    public void reader() {
        while (!flag) { // 线程B可能永远看不到 true！
            // 空循环
        }
        System.out.println("Exit loop!");
    }
}

问题：线程B可能一直读取自己缓存中的 flag = false，陷入死循环。 修复：加上 volatile

ounter(line
private volatile boolean flag = false;

现在，线程A修改 flag 后，会强制刷新到主内存；线程B读取时，会强制从主内存加载，保证看到最新值。

2.4 原子性缺失：volatile不是万能的

public class Counter {
    public volatile int count = 0;

    public void increment() {
        count++; //  不是原子操作！
    }
}

count++ 实际是三步操作：

1. 读取 count
2. 加 1
3. 写回 count

即使 count 是 volatile，多个线程同时执行时仍可能互相覆盖，导致结果小于预期。

解决方案：

• 使用 synchronized
• 使用 AtomicInteger
• 使用 Lock

三、内存重排序（Memory Reordering）揭秘

3.1 什么是内存重排序？

内存重排序，是指编译器、CPU 或运行时系统为了提高执行效率，在不改变单线程语义的前提下，调整指令执行顺序的行为。

注意：重排序在单线程下无感知，但在多线程下可能造成严重问题！

3.2 重排序的三种来源

3.3 经典案例：DCL 单例模式中的重排序陷阱

public class Singleton {
    private static Singleton instance; //  没有 volatile

    private Singleton() {}

    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton(); //  重排序风险！
                }
            }
        }
        return instance;
    }
}

instance = new Singleton() 实际分为三步：

1. 分配内存空间
2. 初始化对象（调用构造方法）
3. 将 instance 指向内存地址

重排序风险：步骤 2 和 3 可能被调换！

→ 线程A执行到第3步（引用已赋值），但第2步（初始化）还没完成→ 线程B看到 instance != null，直接使用 → 访问未初始化对象 → 空指针或数据错误！

修复方案：

private static volatile Singleton instance; //  加上 volatile

volatile 插入内存屏障，禁止“初始化”和“赋值引用”之间的重排序，确保对象完全初始化后才被其他线程看到。

3.4 另一个重排序示例：变量赋值顺序错乱

int a = 0;
boolean flag = false;

public void writer() {
    a = 1;      // ①
    flag = true; // ②
}

public void reader() {
    if (flag) { // ③
        int i = a * a; // ④ → 理论上 i=1，实际可能 i=0！
    }
}

问题：由于重排序，线程1可能先执行②再执行① → 线程2看到 flag=true 但 a=0 → i=0

修复：

ounter(line
volatile boolean flag = false;

现在，① happens-before ②，③能看到②时，也一定能看到①。

四、如何禁止重排序？Java 的内存屏障机制

Java 通过内存屏障（Memory Barrier / Memory Fence） 来禁止重排序。

volatile 变量的读写会插入以下屏障：

• 写 volatile 前 → StoreStore 屏障：确保之前的写入先完成
• 写 volatile 后 → StoreLoad 屏障：确保写入对其他 CPU 可见
• 读 volatile 后 → LoadLoad / LoadStore 屏障：确保后续读写不会被提前

这些屏障阻止了编译器和 CPU 的重排序优化，从而保证了“程序顺序”在多线程下的语义一致性。

五、volatile 与 synchronized对比

六、volatile适用场景推荐

推荐使用场景：

1. 状态标志位

private volatile boolean shutdownRequested;
public void shutdown() { shutdownRequested = true; }
public void doWork() { while (!shutdownRequested) { ... } }

2. 一次性安全发布（如 DCL 单例）

private static volatile Singleton instance;

3. 独立观察（一个线程写，多个线程读）

private volatile String config;

4. “Volatile Bean” 模式（所有字段都是 volatile 的简单数据容器）

不适用场景：

• i++、count += 1 等复合操作
• 依赖当前值的计算（如 x = x + 1）
• 需要原子更新多个变量

七、底层原理：Java 内存模型（JMM）与 Happens-Before

volatile 的语义由 Java 内存模型（JMM） 定义：

对一个 volatile 变量的写操作，happens-before 于任意后续对该变量的读操作。

这意味着：

• 写操作的结果对读操作可见
• 写操作之前的代码不会重排序到写操作之后
• 读操作之后的代码不会重排序到读操作之前

这是 volatile 能保证可见性和有序性的理论基础。

八、总结与最佳实践

核心要点总结：

• volatile = 可见性 + 有序性（禁止重排），≠ 原子性
• 内存重排序是性能优化的副产品，在多线程下可能引发严重 Bug
• DCL 单例必须加 volatile，否则可能返回未初始化对象
• i++ 即使加了 volatile 也不安全，必须用 AtomicInteger 或锁
• volatile 是轻量级同步机制，适合“一个写、多个读”的状态控制场景

最佳实践建议：

1. 状态标志首选 volatile —— 轻量、高效、无锁
2. 复合操作用 Atomic 类或 synchronized
3. DCL 单例一定要加 volatile
4. 不确定时，优先使用 java.util.concurrent 包中的工具类
5. 学习 JMM 和 happens-before，是掌握并发的必经之路

结语

volatile 虽小，却承载着 Java 并发世界中“可见”与“有序”的重任。理解它，不仅是为了写出正确的并发代码，更是为了在面对诡异多线程 Bug 时，能一眼看穿本质，从容应对。

“你写的代码顺序 ≠ 实际执行顺序 ≠ 其他线程看到的顺序”—— 用 volatile，让“看到的顺序”符合你的预期。