1. 一个“看起来没问题”的程序，为什么运行结果会让人崩溃？
1.1 这段代码真的会死循环吗
先看一段很经典的代码，我每次讲 JMM 都会拿它开场：
public class VisibilityTest { private static boolean flag = true; public static void main(String[] args) throws InterruptedException { Thread worker = new Thread(() -> { while (flag) { // 空循环 } System.out.println("worker 线程退出"); }); worker.start(); Thread.sleep(1000); flag = false; System.out.println("主线程已把 flag 置为 false"); } }凭直觉，worker线程应该在一秒后看到flag变为false，然后打印退出信息。但在某些 JVM 配置、某些 CPU 平台上，这个程序会一直跑下去，主线程明明已经改了flag，worker线程却像瞎了一样看不到。我第一次跑出这个现象时，第一反应是“编译器出 bug 了”，后来才意识到，这是我自己的代码违反了 Java 内存模型（JMM）的约定，而不自知。
这里要理解一个关键点：flag = false在主线程执行，while (flag)的读取在另一个线程执行。两个线程之间没有任何同步机制，那么 JMM 允许 JVM 对这段代码做各种“激进”的优化——包括把flag的值缓存到 CPU 寄存器里，导致worker线程永远读的是旧值。
这个例子引出了 JMM 存在的意义：JMM 是一组规则，它定义了多线程读写共享内存时，什么行为是被允许的，什么行为会出错，以及在什么条件下一个线程的写入对另一个线程可见。
1.2 JMM 管的三件事：可见性、有序性、原子性
聊 JMM 之前，先理清它到底在管什么。业界总结成三个词：可见性、有序性、原子性。
- 可见性：一个线程修改了共享变量，另一个线程能不能立刻（或者说在某个约定时刻）看到这个修改。上面那个例子就是典型的可见性问题。
- 有序性：代码写的顺序，不一定是实际执行的顺序。编译器和 CPU 都可能为了性能打乱指令顺序，这在单线程里不影响结果，但多线程下会出问题。
- 原子性：一个操作要么全部执行成功，要么全部不执行，中间不能被中断。比如
i++这种“读-改-写”操作，表面上是一行代码，底层是三条指令，完全可能被另一个线程的操作插进去。
JMM 的设计目标就是：在保证程序正确性的前提下，尽量给 JVM、编译器和 CPU 留出优化空间。换句话说，JMM 不是教你写并发代码的 API，而是一份“契约”——你按规则用同步工具（synchronized、volatile、Lock等），我就保证你在多线程下看到合理的结果；你不按规则来，程序什么奇怪行为都可能发生，JVM 和 CPU 都没有错。
网上很多文章喜欢把 JMM 直接等同于“Java 内存布局”，说主内存、工作内存什么的。这其实是个比喻模型。JMM 里说的“主内存”和“工作内存”，不是 JVM 运行时数据区里的堆、栈，而是对底层硬件缓存机制的抽象。所以别把这两套概念搞混，否则后面理解 happens-before 规则时会很别扭。
2. 追到硬件层：CPU缓存、指令重排和内存屏障
2.1 缓存一致性协议和 MESI
JMM 为什么搞得这么复杂？根源在 CPU。现代 CPU 的处理速度和内存访问速度差了两个数量级以上，如果每个核都直接访问内存，CPU 绝大部分时间都在等待，性能没法看。于是硬件设计者在 CPU 和内存之间加了一层又一层缓存（L1、L2、L3），每个 CPU 核心有自己的 L1/L2，多个核心共享 L3。
核心之间缓存不共享，就带来一个问题：核心 A 改了某个变量的值，这个新值还在 A 的 L1 缓存里，核心 B 却在自己的缓存里读到旧值。为了保持一致性，硬件搞出了缓存一致性协议，最典型的是MESI 协议。它把缓存行标记为四种状态：Modified（修改）、Exclusive（独占）、Shared（共享）、Invalid（失效）。
当核心 A 写入一个缓存行时，它需要先向总线发送消息，让其他核心把这个缓存行标记为 Invalid。其他核心如果后续要读这个变量，发现自己缓存里的数据是 Invalid，就不得不重新从内存或其他缓存拉最新值。这套机制保证了缓存层面的可见性。
但 MESI 不是万能的。它保证的是“缓存行级别的一致性”，不是“变量级别的一致性”。如果一个 long 类型变量跨了两个缓存行，或者多个变量挤在同一个缓存行（出现伪共享），情况会更复杂。而且，即使有 MESI，CPU 仍然可能因为**写缓冲器（store buffer）和失效队列（invalidate queue）**的存在，延迟让其他核心看到自己的写入。这就是为什么硬件层面还需要更明确的内存屏障指令。
2.2 指令重排：编译器、CPU、存储系统
除了缓存可见性问题，指令重排也是多线程程序出错的重要源头。重排发生在三个层次：
- 编译器重排：Java 编译器（JIT，特别是 C2 编译器）在生成机器码时，会根据对代码语义的分析，调整指令顺序。只要单线程语义不变，编译器就认为怎么排都一样。
- CPU 乱序执行：现代 CPU 采用流水线、多发射技术，在保证单线程结果一致的前提下，允许后续指令提前执行。
- 存储系统重排：即使 CPU 不乱序，内存系统也可能因为缓存和写缓冲器的影响，让写入的顺序和实际对外可见的顺序不一致。
值得强调一点：这些重排都是“好心办坏事”的典型。它们都是为了提高性能，而且在单线程环境下绝对不违反程序语义。如果单线程下都会出错，那 CPU 和编译器就是不称职的，它们的设计目标就是在单线程下让你感知不到重排。但在多线程共享变量的场景下，重排会破坏你直觉中的“代码顺序”。
2.3 内存屏障解决了什么问题
为了对付缓存可见性和指令重排，硬件提供了一组特殊指令，叫内存屏障（Memory Barrier / Memory Fence）。它的作用简单说就是：禁止屏障前后的指令跨越屏障重排，并且确保某些缓存操作能及时“刷出去”或被“看进来”。
内存屏障大致分几类：
- 读屏障（Load Barrier）：确保屏障之前的读操作完成后，后续读操作才可能执行。
- 写屏障（Store Barrier）：确保屏障之前的写操作对所有处理器可见后，后续写操作才可能执行。
- 全屏障（Full Barrier）：兼具读和写的效果。
Java 层面的volatile、synchronized、Lock等关键字，最终在底层都会对应到这些硬件内存屏障指令上。所以 JMM 是横跨三层的“翻译官”：把程序员写的 Java 代码，翻译成编译器规则、JVM 规则，最后落到 CPU 指令上。
3. volatile 的完整语义：该信的和不该信的
3.1 volatile 保证的可见性
回到文章开头的死循环例子。如果给flag加上volatile修饰：
private static volatile boolean flag = true;这在 JMM 中意味着什么？简单说：
- 写一个
volatile变量的操作，会被 JVM 插入一个 Store-Store 屏障 + Store-Load 屏障。效果是：这个写入会强制刷新到主内存，而不是只停留在 CPU 缓存或写缓冲器里。 - 读一个
volatile变量的操作，会被插入 Load-Load 屏障 + Load-Store 屏障。效果是：读取时不能从自己缓存的旧值里拿，必须从主内存（或能反映最新值的缓存层级）里读。
所以在flag被声明为volatile后，主线程写入false时，JVM 保证这个新值能对其他线程可见；worker 线程读取时，也保证能拿到最新值，而不是缓存里的旧值。死循环问题就解决了。
不过别高兴太早。MESI 协议在大多数现代 x86 机器上，本来就能让缓存行失效消息及时传播，所以纯从可见性角度，volatile的开销有时被低估了。真正让volatile变贵的是它附带的有序性保证，也就是下面这部分。
3.2 volatile 禁止指令重排
volatile的第二个语义是禁止重排序。JMM 针对volatile制定了专门的规则：
| 能否重排 | 第二个操作 |
|---|---|
| 第一个操作 | 普通读/写 |
| 普通读/写 | —— |
| volatile 读 | 不可以（后面的读/写不能和 volatile 读重排，读-读/读-写） |
| volatile 写 | 不可以（volatile 写不能和后面的普通写重排，写-写） |
这张表读起来有点绕，我用自己的话翻译一下：
volatile写的语句，它之前的所有普通写操作都不能被重排到它之后；volatile读的语句，它之后的所有普通读/写操作都不能被重排到它之前；volatile写和volatile读之间也不能互相重排。
这种“禁止重排”的效果，本质上是通过插入内存屏障实现的。初始化一个对象然后发布给其他线程，是volatile这个特性最经典的练兵场，后面我专门用一个章节讲。
3.3 volatile 不保证原子性：i++ 的真相
这是面试里最容易被问倒的地方。volatile不能保证原子性，为什么？
看这个例子：
public class VolatileCounter { private static volatile int count = 0; public static void increment() { count++; // 这行不是原子的 } }count++在字节码层面是getstatic（读）、iconst_1（常量1）、iadd（加）、putstatic（写）四个指令。volatile能保证getstatic读到最新值，也能保证putstatic写入后立刻对其他线程可见，但它管不了“读和写之间被另一个线程插一脚”这种情况。
两个线程同时执行count++，完全可能出现下面的交错：
- 线程 A 读到 count = 10
- 线程 B 读到 count = 10
- 线程 A 计算得 11，写回
- 线程 B 计算得 11，写回
结果是 count 从 10 变成 11，但两个线程各加了一次，正确结果应该是 12。volatile管不了这个，因为它在读和写之间没有加锁。
如果你想要原子递增，应该用AtomicInteger，或者synchronized/Lock把读-改-写包起来。volatile适合的场景是：一个变量只被单个线程写，但被多个线程读。最典型的就是状态标志位，还有下面要说的 DCL 单例。
3.4 DCL 单例：volatile 最经典的工程应用
双重检查锁（Double Checked Locking）模式，是volatile最有名的应用之一：
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(); // 问题所在 } } } return instance; } }如果instance不加volatile，这段代码在高并发下可能返回一个“半初始化”的对象。原因就在new Singleton()这行——它不是一个原子操作，底层要经历三步：
- 分配内存空间
- 调用构造方法初始化对象
- 把
instance引用指向这块内存
问题在于，编译器和 CPU 可能把第 2 步和第 3 步重排。如果线程 A 先执行了“指向内存”的操作，instance已经不为null，但对象还没完成构造；线程 B 进来看到instance != null，直接返回这个未完成初始化的对象，使用时就可能出诡异问题。
加上volatile之后，JMM 禁止了“把构造方法的写操作重排到引用赋值之后”，也就是保证了：只要instance引用对外可见，它指向的对象一定是构造完整的。
这是我强烈建议把volatile用在实际代码里的第一个场景。也是我在面试中考察候选人时，特别喜欢问的一个点——能解释清楚“为什么 DCL 要加 volatile”，说明对 JMM 的有序性语义理解到位了。
4. happens-before：JMM 的“定海神针”
4.1 八条规则逐条拆解
如果用一句话概括 JMM 的实质，那就是 happens-before 规则。happens-before 不是一个“发生时间先后”的概念，而是“可见性保证”的概念——如果操作 A happens-before 操作 B，那么 A 的执行结果对 B 是可见的，而且 A 的执行顺序在逻辑上先于 B。
JMM 规定了八条规则，我挑最重要的几条拆开讲：
1. 程序次序规则（Program Order Rule）：在一个线程内，按照代码顺序，前面的操作 happens-before 后面的操作。注意，这只保证单线程视角下的逻辑顺序，不排斥指令重排。
2. 锁规则（Monitor Lock Rule）：对一个锁的解锁（unlock）happens-before 于后续对同一个锁的加锁（lock）。这是synchronized和ReentrantLock可见性保证的根基。
3. volatile 变量规则：对一个volatile变量的写，happens-before 于后续对该volatile变量的读。这里的“后续”指的是时间上的后续。
4. 传递性（Transitivity）：如果 A happens-before B，且 B happens-before C，那么 A happens-before C。这规则看着废话，实际上极其关键，因为很多可见性保证要靠它串联起来。
5. 线程启动规则（Thread Start Rule）：Thread.start()调用 happens-before 于被启动线程中的每一个动作。
6. 线程终止规则（Thread Termination Rule）：线程中的所有操作，happens-before 于其他线程检测到该线程终止的那一刻（比如join()成功返回）。
7. 线程中断规则（Thread Interruption Rule）：对线程的interrupt()调用 happens-before 于被中断线程检测到中断事件（比如抛出InterruptedException，或者检测到isInterrupted()返回值）。
8. 对象终结规则（Finalizer Rule）：对象构造函数的结束 happens-before 于finalize()方法的开始。
这八条规则加在一起，就是 JMM 给程序员的核心承诺。只要你的操作之间存在 happens-before 关系，JVM 就会保证你读到的是最新值；如果没有这层关系，你就不能对读取结果做任何假设。
4.2 用 happens-before 推导经典案例
光背规则没用，得会推。来看一个经典的可见性场景：
// 线程 A sharedConfig = loadConfig(); // 1: 普通写 ThreadB.start(); // 2: 启动线程 B // 线程 B String config = sharedConfig; // 3: 普通读根据线程启动规则，操作 2 happens-before 操作 3。根据程序次序规则，操作 1 happens-before 操作 2。再根据传递性，操作 1 happens-before 操作 3。所以线程 B 读sharedConfig时，一定能看到线程 A 的写入。这里不需要加volatile或锁，因为Thread.start()本身就建立了 happens-before 关系。
再看join()的场景：
// 线程 A sharedResult = compute(); // 1: 普通写 threadA.join(); // 2: 等待线程 A 结束 // 主线程 int result = sharedResult; // 3: 普通读线程终止规则说，线程 A 的所有操作 happens-beforejoin()成功返回。程序次序规则又说join()返回后的代码 happens-before 操作 3。传递性一推，线程 A 里对sharedResult的写入，对主线程是可见的。这也是为什么join()之后去读另一个线程产生的数据，是安全的。
4.3 为什么传递性这么重要
传递性这条规则最容易被忽视，但它是 JMM 里最体现“设计功力”的一环。
举个例子，经典的“安全发布”问题。假设有两个变量：
static int x = 0; static volatile int y = 0; // 线程 A x = 42; // 1: 普通写 y = 1; // 2: volatile 写 // 线程 B while (y != 1) { } // 3: volatile 读 int value = x; // 4: 普通读我们来推一下：
- 程序次序规则：1 happens-before 2
- volatile 规则：2 happens-before 3
- 程序次序规则：3 happens-before 4
- 传递性：1 happens-before 4
结论是：线程 B 读取x时，一定能看到线程 A 写入的 42。即使x不是volatile，也无需加锁。这就是volatile写入“顺便”带来的可见性溢出效果。很多并发框架就是利用这种传递性，用一个volatile状态变量来“托底”一批普通变量的发布。
理解传递性之后，你就不会再机械地认为“普通变量在另一个线程里永远不可见”——只要存在一条完整的 happens-before 链条，它就可见。
5. 从 JSR-133 到 CPU 指令：内存屏障到底怎么插
5.1 JSR-133 的重排序规则表
JMM 的规范主要来自 JSR-133（Java Specification Request 133），它在 Java 5 时代修订完成，直到今天仍然是 JMM 的事实标准。规范里给了编译器一张“重排序禁令表”，决定哪些情况下编译器必须放弃优化。
我整理一个简化版的规则，方便理解：
| 重排序类型 | 是否允许 |
|---|---|
| 普通读 -> 普通写 | 允许（单线程语义不变即可） |
| 普通读 -> volatile 写 | 不允许 |
| volatile 写 -> 普通读/写 | 不允许（volatile 写之后的普通操作不能越到它前面） |
| volatile 读 -> 普通读/写 | 不允许（volatile 读之后的普通操作不能越到它前面） |
| 普通读/写 -> volatile 读 | 允许（大多数情况下） |
| volatile 写 -> volatile 读 | 不允许 |
这些规则不是随便定的。它们的共同目的是保证：一个线程对volatile变量的操作，在另一个线程视角下，能够成为共享数据可见性的“分界线”。volatile写像一个“发布点”，volatile读像一个“订阅点”，普通变量只能围绕它们做有限的流动。
5.2 四类内存屏障在 x86 下的真实表现
JVM 在插入屏障时会根据 CPU 架构做区别对待。内存屏障在 JVM 层面被抽象为四类：
- LoadLoad：禁止前面的读和后面的读重排。
- StoreStore：禁止前面的写和后面的写重排。
- LoadStore：禁止前面的读和后面的写重排。
- StoreLoad：禁止前面的写和后面的读重排，并且要求前面的写对所有处理器可见之后，才能执行后面的读。这是代价最高的一类屏障。
在 x86 架构下，CPU 有较强的内存模型（TSO，Total Store Order），除了 StoreLoad 需要显式的mfence/lock指令外，其他三类屏障在绝大多数情况下是“空操作”。这就是为什么在 x86 服务器上跑并发程序，volatile的额外开销看起来没那么夸张。但在 ARM、PowerPC 等弱内存模型下，这些屏障都有真实的指令开销，volatile的性能影响会明显得多。
这里有个很重要的认知点：JMM 的规则是跨平台统一的，但底层实现是平台相关的。你在 x86 上调好的并发代码，换到 ARM 的安卓手机上，行为细节可能完全不同。所以写并发代码时，不要依赖某个具体硬件平台的“幸运结果”，一定要按 JMM 的规则来。
5.3 保守策略与性能权衡
JMM 规范其实允许 JVM 采用更保守的策略——比如把所有普通读/写都当成volatile来处理，这样肯定满足规则，但性能会差得离谱。JVM 工程师需要做的是在“严格遵守 JMM 规则”和“尽可能保留优化空间”之间找平衡。
HotSpot JVM 里有个关键概念叫ObjectMonitor和内存屏障插入点分析。在实际运行中，JIT 编译器会分析代码的关键路径，在适当位置插入屏障。比如：
- 对
volatile写，JVM 会插入一个StoreStore屏障（禁止前面普通写越过）和一个StoreLoad屏障（保证写后读的是新值）。 - 对
volatile读，JVM 会插入一个LoadLoad屏障（禁止后面的普通读越过）和一个LoadStore屏障（禁止后面的普通写越过）。
这些插入策略是 JIT 优化的结果。说白了就是“用最少的屏障，满足 JMM 的规则”。
6. 面试和实战：把 JMM 转成生产力
6.1 面试中最容易踩的坑
JMM 相关话题在 Java 面试中出现频率极高，我面试过的候选人里，十个有八个会在几个问题上翻车，我总结一下：
坑一：把 JMM 说成 Java 内存分区。有些候选人一开口就是“JMM 分为主内存、工作内存，堆和栈怎么样”。这是两套概念。JMM 里的主内存/工作内存是抽象模型，不是 JVM 运行时数据区。当然也不能说完全没关系——JMM 的抽象确实参考了底层 CPU 缓存结构，但和“堆、栈、方法区”完全是两码事。
坑二：认为 volatile 保证原子性。这个错得非常典型。记住：volatile只能保证可见性和有序性，不保证原子性。凡是涉及“读-改-写”复合操作（i++、count += 1、list.add()这种），volatile都救不了。
坑三：死记硬背 happens-before 条例。面试官真正想听的，是你能不能解释“为什么 Thread.start() 之前写的变量，在子线程里一定可见”“为什么 join() 之后读结果安全”。如果只会背规则不会推导，说明没有内化 JMM 的核心思想。建议面试前自己推几遍“传递性+volatile规则+锁规则”的组合案例。
坑四：不区分“时间先后”和“happens-before”。两个操作即使时间上先后发生，如果没有 happens-before 关系，也不保证后者能看到前者的结果。JMM 只认 happens-before 这条逻辑链，不认你的“直觉”。这个点我会专门设一个追问环节，经常能难倒不少人。
6.2 实战排查工具与经验
实际工作中排查并发问题，光靠肉眼读代码效率太低，我常用的工具和手段有这几个：
jcstress：JMM 压力测试框架。这是 OpenJDK 官方的并发正确性测试工具，专门用来验证在 JMM 规则下，某些代码是否可能产生意外结果。它能自动探索各种线程交错和优化场景，比自己写多线程测试靠谱得多。属于把 JMM 规则“跑出来给你看”的工具。
HSDIS / JITWatch：看汇编代码。有时候你想确认 JVM 到底有没有插入内存屏障，最快的方法是把热点代码的汇编输出看一遍。加上-XX:+PrintAssembly参数，配合 JITWatch 可视化，就能看到volatile写前后有没有lock指令或者mfence。这是验证“JVM 实现了 JMM 规则”最直观的手段。
Arthas + 线程 Dump：死循环排查。回到文章开头的死循环问题，真在线上遇到时，用jstack抓线程栈，能看到worker线程一直卡在VisibilityTest.main对应的行上。这时候再回头看代码，大概率是可见性问题，而不是程序“没执行到”那行。这种经验我踩过好多次。
静态检查与 Code Review 清单。我会在自己的团队推行一份简短的并发 review 清单：
- 共享可变变量有没有加同步或 volatile？
- volatile 是否被用于读-改-写复合操作？
- 锁的粒度是否覆盖了所有相关读写路径？
- 依赖 Thread.start()/join() 建立的可见性，是否真的存在？
- 发布对象时，是否依赖了 happens-before 传递链？
这几条检查下来，能拦截绝大多数并发隐患。
6.3 关于“学 JMM 到底有什么用”的一点体会
往浅了说，JMM 是 Java 并发编程的理论根基；往深了说，它反映了计算机系统里“性能优化”和“正确性约束”这对核心矛盾。我自己的学习路径是：先被并发 bug 折磨，再回头啃 JSR-133，然后到硬件层面看 CPU 手册，最后才真正把 JMM 串成体系。这个过程倒过来走（先背规范再写代码）也不是不行，但容易学成“面试八股”。
如果你现在正在准备面试，或者刚接手一个并发问题多到爆炸的系统，我建议你做三件事：第一，用 jcstress 验证自己对 volatile 和锁规则的推导；第二，把synchronized、volatile、Thread.start()/join()这几条 happens-before 链画成图，每天推一遍；第三，遇到线上诡异问题时，别急着换写法碰运气，先问自己“这里到底存不存在 happens-before 关系”。把这三个习惯坚持下来，比收藏二十篇深度文章都管用。
