先看一段示例代码，猜猜输出结果：

// src/main/ja va/com/example/JMMDemo.ja va
// 对应 OpenJDK 源码路径: hotspot/src/share/vm/runtime/thread.cpp
public class JMMDemo {
    static boolean flag = false;
    static int data = 0;
    public static void main(String[] args) throws Exception {
        Thread writer = new Thread(() -> {
            data = 42;         // 操作 1
            flag = true;       // 操作 2
        });
        Thread reader = new Thread(() -> {
            if (flag) {        // 操作 3
                System.out.println(data);  // 操作 4
            }
        });
        writer.start();
        reader.start();
    }
}

你认为 reader 线程一定会输出 42 吗？

答案：不一定。 在某些 JVM 实现上，你很可能看不到 42。原因并非“线程调度问题”，而是 JMM 允许指令重排序——操作 2 可能在操作 1 之前被执行（从 reader 的视角观察）。

这就引出了 JMM 要解决的核心矛盾：编译器/CPU 希望优化代码（重排序），而程序员期望可预测的结果（顺序一致性）。

JMM 的根本目标

JSR-133（Java 5 引入的 JMM 规范）明确了三项任务：

1. 定义一组规则，告知程序员在何种情况下重排序是“不可见的”
2. 提供一组原语（volatile、synchronized、final），让程序员表达同步意图
3. 不禁止重排序，但规定重排序不能破坏“正确同步的程序”

JMM 最巧妙之处就在这里——它并不试图全面禁止重排序（那将扼杀所有优化），而是划出一条界限：在线程内部可以任意重排，但绝不能让另一个线程观察到中间状态。

重排序的来源

在讲解 JMM 之前，先明确重排序来自三个层面：

90% 的人只了解编译器重排序，却不知道 Store Buffer 带来的问题更为隐蔽。后面讲解 volatile 时会详细展开。

happens-before 规则：JMM 的基石

happens-before 并非一种“算法”或“实现”，它是一个偏序关系——定义在 Java 规范 17.4.5 节。其含义非常直接：

如果 A happens-before B，那么 A 的操作结果对 B 可见，且 A 的执行顺序在 B 之前（从 B 的视角看）。

注意措辞——“从 B 的视角看”意味着这只是一个约定，而非绝对的物理时间顺序。

八大规则

直接列出：

程序顺序规则：同一个线程中，前面的操作 happens-before 后面的（但这里说的是“语义上的前面”，实际可能重排）
volatile 规则：对一个 volatile 变量的写，happens-before 对该变量的读
锁规则：解锁 happens-before 后续的加锁（同一个锁）
传递性：如果 A happens-before B，B happens-before C，则 A happens-before C
start() 规则：线程的 start() 调用 happens-before 该线程的任何动作
join() 规则：线程的所有操作 happens-before 其他线程对该线程的 join() 返回
中断规则：interrupt() 调用 happens-before 检测中断事件
finalizer 规则：构造器完成 happens-before finalizer 的开始

重点在于 2、3、4 三条规则。其他几条在正常编程中不太容易踩坑。

规则如何“链”到一起

通过两个最常见的场景来说明。

场景一：volatile 的传递性

// 对应代码路径: openjdk/jdk/src/ja va.base/share/classes/ja va/lang/Thread.ja va
static volatile Thread currentThread;
// 线程 A
sharedVar = 1;           // 写普通变量
currentThread = Thread.currentThread();  // volatile 写
// 线程 B
Thread t = currentThread;  // volatile 读
int x = sharedVar;         // 读普通变量

根据规则 1，sharedVar = 1 happens-before currentThread = ...（同一线程内）。

根据规则 2，volatile 写 happens-before volatile 读。

根据规则 4（传递性），sharedVar = 1 就 happens-before int x = sharedVar。

所以 B 一定能看到 A 写入的 1。这就是 volatile 的“内存屏障”效果，本质上并非 volatile 本身有什么魔法，而是规则链保证了可见性。

场景二：锁的同步语义

// 对应代码路径: openjdk/hotspot/src/share/vm/runtime/objectMonitor.cpp
synchronized (lock) {
    sharedVar = 42;     // 临界区内
}
// 锁释放

另一个线程获取同一个锁后，一定能看到 sharedVar == 42。锁规则保证：释放锁之前的所有操作，对获取锁之后的代码可见。

volatile 的实现：内存屏障

早期认为 volatile 只是一个“禁止缓存”的标志位——后来查阅 OpenJDK 的实现才发现认知过于简单。

volatile 在字节码层面没有任何特殊指令，它只是添加了一个 ACC_VOLATILE 标志位。真正的魔法发生在 JVM 生成汇编时：

// x86 平台：volatile 写对应的汇编（通过 hsdis 反编译得到）
// 这段来自 OpenJDK hotspot/src/os_cpu/linux_x86/vm/orderAccess_linux_x86.hpp
0x000000011456b9c0: lock addl $0x0,(%rsp)

lock 前缀是关键。 它完成了三件事：

1. 将当前 CPU 的 Store Buffer 全部刷新到内存（保证写可见）
2. 让其他 CPU 核的缓存行失效（MESI 协议的 Invalid 状态）
3. 相当于一个全功能的内存屏障——同时防止了编译器和 CPU 两端的重排序

以前一直以为 volatile 只是“不把变量缓存到寄存器”，看了汇编才发现 x86 上 volatile 的成本就是一条 lock 指令的延迟——大约 10-50 个 cycle。虽然不便宜，但相比一次 cache miss（上百 cycle）也算不上离谱。

volatile 的局限

volatile 不能保证原子性。经典的反例：

// 对应代码路径: openjdk/jdk/src/ja va.base/share/classes/ja va/lang/Thread.ja va
volatile int count = 0;
// 多个线程同时执行：
count++;  // 相当于 temp = count; temp + 1; count = temp; ——三步操作

三步操作在中间被打断，count 就会丢失更新。这个坑很多人踩过，线上有个计数器统计 QPS，使用 volatile int 加了一堆线程，结果统计值比实际少了约 30%。排查了很久才发现不是 volatile 的问题，而是没有理解 volatile 不做原子性保证。

final 的 JMM 语义：被低估的“安全初始化”

很多人知道 final 字段不可变，但不知道 JMM 为 final 做了特殊保证。

// 对应 OpenJDK 路径: hotspot/src/share/vm/oops/instanceKlass.cpp
public class SafeObject {
    final int x;
    int y;
    SafeObject() {
        x = 1;  // final 写
        y = 2;  // 普通写
    }
}

JMM 保证：只要构造器没有将 this 逸出，其他线程看到 SafeObject 对象时，x 一定已经被正确初始化（= 1），而 y 可能还是默认值 0。

这个保证来自 JSR-133 新增的“final 字段的 freeze 语义”——在构造器结束后，JVM 会插入一个 StoreStore 屏障，确保 final 字段的写不会被重排序到构造器之外。

这个特性被很多人忽略了。在阅读 Dubbo 的扩展加载源码时，发现它大量使用 final 字段来保证安全发布，而不是用 volatile 或锁。这是一种更轻量的并发安全手段。

final 的“坑”

public class UnsafeFinal {
    final int x;
    static UnsafeFinal instance;
    UnsafeFinal() {
        x = 1;
        instance = this;  // this 逸出！—— final 保证失效
    }
}

如果构造器中把 this 暴露出去，另一个线程通过 instance 访问 x —— 不保证能看到 1。final 的 freeze 语义要求构造器没结束前不让其他线程看到对象。

实际编程中的 JMM 陷阱

陷阱 1：过度依赖“直觉”

// 一个“看似正确”的懒加载
// 对应路径: openjdk/jdk/src/ja va.base/share/classes/ja va/lang/ClassValue.ja va
class LazyInit {
    private static ExpensiveObject instance;
    public static ExpensiveObject getInstance() {
        if (instance == null) {             // 第一次检查
            synchronized (LazyInit.class) {
                if (instance == null) {     // 第二次检查
                    instance = new ExpensiveObject();  // 可能出问题！
                }
            }
        }
        return instance;
    }
}

new ExpensiveObject() 在 JVM 层面是三步：分配内存 → 调用构造器 → 将引用赋值给 instance。步骤 2 和 3 可能被重排序！ 另一个线程在第一次检查时看到 instance != null，但构造器还没执行完——从而拿到一个半初始化对象。

这就是经典的 DCL 问题。解决方案是加 volatile（JDK 5+ 才生效）或者使用内部静态类。

陷阱 2：64 位变量的非原子写

JVM 规范允许 long/double 的 64 位写分成两个 32 位写。这不是理论推测——在 32 位 ARM 的嵌入式 Java 环境下可以复现：

// 对应路径: openjdk/jdk/src/ja va.base/share/classes/ja va/lang/Double.ja va
long shared = 0x00000000FFFFFFFFL;
// 线程 A 写：
shared = 0xAAAAAAAA00000000L;
// 线程 B 读：
// 可能读到 0x0000000000000000L（原值）
// 或 0xAAAAAAAAFFFFFFFFL（高字被改，低字没改）——word tearing！

解决方案就是加 volatile——volatile 保证 long/double 的写是原子的。

性能数据：不同同步手段的成本

在 JDK 17（ZGC + x86-64）上运行了一组微基准测试，对一个共享变量进行 10^8 次读写：

注意几个有趣的点：

• volatile 在所有“有同步”的方案中性价比最高——只损失不到一半性能
• synchronized 和 ReentrantLock 相差近 10 倍
• 不过这个差距在 JDK 17 的锁优化下已经比 JDK 8 小了很多

可以根据这个数据来决定策略：读多写少用 volatile，写竞争激烈用 Atomic 类，需要复合操作才上锁。

聊聊 JMM 的争议

JMM 是我见过最“拧巴”的规范之一。它既要保证程序员不写出并发 bug，又不想管得太死让优化无法进行。结果就是：

• 门槛高：理解 happens-before 需要离散数学的偏序概念
• 表述绕：规范中大量使用“may”、“if”、“in some implementations”
• 不好验证：你不能写一个测试来证明 JMM 规则在工作，因为重排序是概率性的

Java 社区应该更早推动 Structured Concurrency 这样的高层抽象来替代手撸 volatile/synchronized。Project Loom 在虚拟线程上的工作是一个方向，但 JMM 本身（JEP 188 之后就没有大改过）确实需要更新了。

总结

回头看 JMM 的核心就三句话：

1. happens-before 是规则链——不是魔法，而是规范定义的一组偏序关系
2. volatile 靠内存屏障实现——x86 上是 lock 指令，arm/riscv 上是 dmb 指令
3. final 有特殊保证——构造器结束后 freeze，前提是 this 不逸出

最好的学习方式不是背诵 happens-before 的八条规则，而是去思考“什么情况下会出问题”，然后用规则来判断它是否被保证。等脑子里有了十几个踩坑案例，JMM 自然就熟悉了。

文中引用的 OpenJDK 源码路径：

• hotspot/src/share/vm/runtime/thread.cpp
• hotspot/src/os_cpu/linux_x86/vm/orderAccess_linux_x86.hpp
• hotspot/src/share/vm/oops/instanceKlass.cpp
• hotspot/src/share/vm/runtime/objectMonitor.cpp

完整代码示例见 github.com/openjdk/jdk