1. 为什么每本Java书都躲不开JMM
做Java开发多年，一开始我对并发编程的认知基本停留在"用synchronized加锁、用volatile修饰共享变量"这种操作层面。真正被逼着去啃JMM（Java Memory Model，Java内存模型），是在一次线上偶发数据错乱的排查现场。两个线程同时操作同一个共享配置对象，代码里该加的锁都加了，但就是间歇性出现一个线程读到旧值的情况。那次之后我才意识到，光是知道"加锁"远远不够，你必须理解锁在内存语义层面到底保证了什么，JMM规定的happens-before关系又是如何兜住可见性和有序性的。这篇内容我想把JMM这套东西掰开揉碎讲清楚，从底层硬件的行为讲到抽象模型，再到日常开发怎么用、排查问题怎么想，一条线走下来，希望能帮你把脑子里那些零散的知识串成一张网。
先说一个很多人都会误解的点：JMM跟JVM的内存区域划分（堆、栈、方法区）不是一回事，甚至跟"物理内存"也没有直接对应关系。JMM定义的是一套跨线程数据可见性的抽象规则，它回答的核心问题是：当线程A修改了一个值，线程B什么时候能看到这个修改？为什么有时候看不到？在编译器、CPU都可能重排序的现实下，哪种顺序是程序必须保持的？
要理解JMM，得先看看底层硬件到底有多"不守规矩"。现在的多核CPU，每个核都有自己的高速缓存（L1/L2，甚至L3是共享的），还有写缓冲区、指令乱序执行等技术。单线程看来完全正常的顺序，在多核视角下，数据的写入可能先落在核的高速缓存里，很久之后才刷到内存中。Java语言要跨平台，就不能依赖某一类CPU的具体行为，必须在语言层面统一出一套对程序员可见的、稳定的内存语义，这就是JMM存在的意义。
所以从设计目标看，JMM要做两件事：第一，规定线程之间如何通过共享内存进行通信，什么情况下一个线程的写入对另一个线程可见；第二，规定哪些重排序是不允许的，给程序员的直觉一个明确边界。这两件事分别对应了可见性和有序性的问题，再加上原子性，就是并发三大特性的全部家底。
如果你只记一句话，那应该是：JMM是Java并发正确性的基石，synchronized、volatile、final、锁工具这些机制的背后，最终都是靠JMM的规则在支撑。
2. 主内存和工作内存：并不是真有"两块内存"
JMM里最容易被误解的就是"主内存"和"工作内存"这两个词。很可能你在网上看到的图是一个CPU连着主内存，每个线程还有自己的工作内存，于是你脑子里浮现出"内存条"和"CPU寄存器"两处物理区域。其实这是一个抽象模型，不是物理结构。
主内存可以粗略理解为所有线程共享的那份数据区，在JVM里大致可以对应堆中共享变量的存储位置。工作内存则是对CPU高速缓存、写缓冲、寄存器、编译器优化后的暂存位置等一整套底层机制的统称，每个线程私有一份。线程操作一个共享变量，不是直接到主内存里改，而是先把主内存的值拷贝到自己的工作内存，在自己的"地盘"上处理，处理完再按某种时机刷回主内存。
这个过程我用一个生活化的类比解释过很多次：把主内存想象成办公室公共区域的公告板，每个线程的工作内存就是各人手边的草稿纸。张三改了一个数字，如果只是写在自己的草稿纸上，没有正式誊到公告板上，李四就算跑去看公告板，也只能看到旧值；就算张三誊到公告板了，李四手边的草稿纸上也未必已经更新。线程之间互相不知道对方草稿纸上是新是旧，各种诡异的问题就来了。
JMM对主内存和工作内存之间的交互，定义了8种原子操作。这8个名字听起来吓人，其实分成三组就好记了：
- 工作内存内部操作：
use（把工作内存的变量值交给执行引擎）、assign（把执行引擎的值赋给工作内存的变量副本） - 在主内存和工作内存之间搬运：
read（从主内存读值到工作内存）、load（把read读到的值装载到工作内存的变量副本）、store（把工作内存的变量值传送到主内存）、write（把store传来的值写入主内存的变量） - 加锁相关：
lock（把主内存变量标记为线程独占）、unlock（释放主内存变量的独占标记）
这些操作之间有严格的约束。例如，read和load必须成对出现，store和write必须成对出现，但不要求连续执行，中间可以插入其他操作；不允许线程丢弃最近一次的assign操作，也就是说，工作内存中修改过的变量，没有store到主内存之前，不能因为后续又赋了新值就直接抛弃旧值的"同步义务"。这些规则本质上是在回答：数据什么时机上行、什么时机下行、能不能省略某一次同步。
说实话，日常写CRUD代码几乎用不到这8个操作的名字，但它是理解volatile和synchronized底层语义的钥匙。volatile修饰的变量，JMM要求每次use之前必须重新load，每次assign之后必须立刻store，相当于绕过了"攒一批再刷"的懒同步机制，强制走"实时同步"通道。synchronized则是在进入临界区时执行刷新关卡，退出时执行让出关卡，把跨线程的可见性边界划得明明白白。
3. happens-before：JMM给程序员的"安全承诺书"
如果你觉得8种操作太底层、太抽象，没关系，JMM还给程序员准备了一套更友好、更常用、分析并发问题时真正的主力工具——happens-before规则。
happens-before的表述很简洁：如果操作A happens-before操作B，那么A的执行结果对B是可见的，并且A的执行顺序在B之前（在允许重排的语义下，指的是A产生结果的操作在B需要这个结果的操作之前完成，并且这个结果必须能传递到B）。这里要注意，happens-before是一种"语义上的先后"，不是"时间线上的先后"，它是JMM对编译器、CPU下达的约束指令，违反了这个约束的重排序是不允许的。
happens-before规则一共有8条，但平常分析问题真正高频使用的是下面几条：
程序次序规则。在同一个线程内，按照代码顺序，前面的操作happens-before后面的操作。注意，这不是说编译器不能重排无关语句，而是说重排不能破坏这个"逻辑先序"的可见性语义。单线程内你几乎感觉不到差异，因为它只保证结果一致性。
锁规则。对一个锁的解锁操作happens-before于对同一个锁的加锁操作。这条是synchronized一切保证的核心：线程A退出同步块之前做的所有共享变量修改，在线程B进入同一个同步块之后，一定全部可见。这里强调的是"同一把锁"，不同锁对象之间没有这个保证。
volatile变量规则。对一个volatile变量的写操作happens-before于对该变量的读操作。所以线程A对volatile变量flag的写入，线程B只要读到flag的最新值，就能看到A在写flag之前做的所有操作的效果。这就是volatile能提供"轻量级可见性"的底层来源——它只保证单次读写的可见性，不保证复合操作的原子性。
传递性。如果A happens-before B，B happens-before C，那么A happens-before C。这条规则的价值在于串联：你代码里可能并没有直接让A和C操作同一个锁、同一个volatile变量，但通过传递性，它们之间也能建立起可预测的同步关系，排查问题时特别常用。
还有几条不常被提起但同样重要的：线程启动规则（对线程的start()调用happens-before于该线程内的任何动作）、线程终止规则（线程内所有操作happens-before于其他线程检测到该线程终止）、中断规则（对线程的interrupt()调用happens-before于被中断线程检测到中断事件）、finalizer规则（对象的构造函数完成happens-before于finalizer开始执行）、传递性前面说了。这些规则合起来，构建了一张"哪些操作之间有可见性保证"的全景图。
工程上分析并发问题，我基本只做两件事：一是找代码里是否存在锁规则、volatile规则、线程启动/终止规则这些"显式同步点"；二是通过传递性推断两个线程操作之间的可见性链条。如果链条断了，那这个并发缺陷不是偶然，而是必然。
拿最常见的一个场景举例：线程A设置config = newConfig; flag = true;，线程B循环检查if(flag) use(config);。如果flag不声明为volatile，也没加锁，那依照JMM，线程B完全可能看到flag == true但config还是旧值，因为A对config的写入happens-before对flag的写入，但这条先后关系只在A线程内部成立，跨线程没有任何规则能把config的修改传递到B。一旦把flag声明为volatile，A写flag就happens-before B读flag，再通过传递性，A写config的结果也对B可见了。这就是很多所谓"优雅停机的标准写法"背后真正的原理。
4. volatile与synchronized：JMM在代码里的两张脸
很多初学并发的人会把volatile和synchronized搞混，要么觉得"volatile比synchronized快，所以能替代它"，要么觉得"有了synchronized就不需要volatile"。这两种想法都不对。搞清楚它们在JMM语义下的真实分工，选择起来就很自然。
4.1 volatile到底保证什么、不保证什么
volatile保证的是可见性和有序性。可见性前面说了：对一个volatile变量的写，后续对该变量的读一定能看到这个写，并且能看到写之前一系列操作的结果。有序性体现在JMM对volatile的特殊约束上：写volatile变量时，JMM会插入内存屏障，禁止前面的普通写操作重排到写volatile之后；读volatile变量时，禁止后面的普通读操作重排到读volatile之前。简单说，volatile划出了"操作之间的隔离墙"，保证它两侧的普通操作不会混到对方阵营去。
volatile不保证的是原子性。经典反例：volatile int count;多线程执行count++，结果仍然是丢失更新。因为count++在字节码层是读、加一、写回三步，三步之间随时可能插入其他线程的操作。volatile只保证每次读都是最新值、每次写都会立刻刷新，但"读旧值→计算→写回"这个整体过程并不是不可分割的。count++要线程安全，必须用synchronized、AtomicInteger或带锁的同步机制。
那什么时候该用volatile？我的经验是三个条件同时满足时：对变量的写操作不依赖于当前值（比如写一个布尔标志、一个固定数值）；该变量不需要与其他状态变量共同参与不变式约束；多线程只有读取这个变量的需求，不需要加锁保护复合操作。典型的场景就是状态标志、开关标记、发布不可变对象引用（比如把volatile引用指向一个新建的不可变配置对象）。
4.2 synchronized为什么既是锁又是"内存栅栏"
synchronized在JMM语义下保证互斥和可见性两条。互斥好理解，同一时刻只有拿到锁的线程能进入临界区。可见性则来自锁规则的强制要求：线程进入synchronized块时，会从主内存重新加载相关变量到工作内存；线程退出synchronized块时，会把这期间修改过的共享变量刷新回主内存。这相当于锁的acquire和release天然携带了内存屏障。
于是我们有了一个重要的推理工具：如果在临界区内写入共享变量A，另一个线程在同一个锁的临界区内读取A，那么写入一定对读取可见，不需要A是volatile。反过来也成立，线程退出临界区后，它写的所有共享变量都会对下一个进入同一把锁的线程可见，甚至不需要那些变量本身带任何修饰。
这解释了为什么并发教科书总说"同步块是可见性的边界"。很多团队的规范里要求"所有共享变量的修改必须发生在锁保护范围内"，本质就是在利用锁的JMM语义，锁定可见性和原子性两条线。
4.3 两者的组合与取舍
实际代码里，volatile和synchronized经常组合使用。一种典型组合是"状态变量用volatile，复合操作加锁"。比如一个缓存加载器，用一个volatile的loaded标志表示缓存是否就绪，加载过程本身用synchronized保证不重复加载。volatile负责跨线程发布状态，锁负责保护临界区内的复杂操作，各管一摊，配合得很干净。
另一种误导很深的观点是"读多写少就该用volatile替代锁"。读写锁、CopyOnWriteArrayList、ConcurrentHashMap这些工具在JMM层面做的事，远不是volatile单变量能替代的。理解JMM之后你再去看java.util.concurrent包的实现，会发现大量volatile字段的存在——它们靠volatile保证字段可见性，靠Unsafe/CAS或synchronized保证原子性，两者互相配合，缺一不可。这也是为什么我常说，JUC源码是检验JMM理解程度的最佳试卷。
5. 用JMM视角拆解三个经典并发陷阱
理论讲多了容易飘，落到具体代码里才有感觉。我挑了三个工作中反复出现、网上提问率极高的场景，用JMM的规则一条条推给他们看。
5.1 双重检查锁与单例的volatile之谜
双重检查锁（Double-Checked Locking，DCL）单例是JMM最经典的考卷。代码长这样：
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()这一步。它在字节码层面大致分三个阶段：分配对象内存、调用构造函数初始化对象、把引用赋给instance。如果编译器把"初始化"和"赋值引用"两步重排了（这在无volatile时是JMM允许的），那线程B可能在instance已经非空但对象还没完成初始化的时候，直接返回这个引用，然后一用就爆炸。volatile在这里的作用就是禁止这两步重排，确保一个线程看到instance != null时，它背后的对象一定已经完整初始化。这个例子每次讲完，都有同行恍然大悟——原来volatile不只是"可见性"，它还在管"有序性"。
5.2 简单的boolean标志：加不加volatile的天壤之别
public class TaskRunner { private boolean stopped = false; public void stop() { stopped = true; } public void run() { while (!stopped) { // do something } } }主线程调用stop()，工作线程在while循环里检查stopped。不加volatile时，工作线程可能永远看不到stopped的最新值，因为它的工作内存里缓存了旧值，主线程的写入没有happens-before关系传递过来。这在循环体很空、循环很快的场景下尤其容易复现，表现为"程序停不下来"。把stopped声明为volatile，主线程写它就是对工作线程读它的happens-before前提，可见性建立，循环正常退出。这也是我建议"所有跨线程的状态标志默认都加volatile"的原因——成本极低，但能消除一整类"偶发停不下来"的玄学问题。
5.3 不同锁对象：看起来都加了锁，实际等于没加
有次帮人排查线上问题，代码大概长这样：一个服务类里有两个方法，方法A加了synchronized(this)，方法B加了synchronized(lockObj)，两个方法都在修改同一个共享Map的key。问为什么高并发下数据还是会错乱。我用happens-before一推就明白了：两个方法用的不是同一把锁，锁规则完全不生效，线程A和线程B之间没有任何可见性关系；就算锁都生效，两个锁也各自管各自的临界区，互相之间根本不存在互斥。这种问题用肉眼看代码很难发现，因为你满眼都是"synchronized"，但从JMM的角度看，锁的身份不明，一切都是白搭。
6. 工程实践：把JMM变成并发代码的"检查清单"
理论的价值在于指导实践。我这里整理了一套自己一直在用的并发代码review清单，每一条都能对应到JMM的具体规则，推荐你也试试。
第一，列出所有被多线程访问的共享变量（包括被锁保护的、volatile的、final的），逐一标注"可见性靠什么保证"。如果某个共享变量既不是volatile，又不在任何锁的保护范围内，也没有final修饰，那它跨线程的可见性就是裸奔状态，出bug只是迟早问题。
第二，检查每个加锁点是否用的是同一把锁。锁规则只对"同一把锁"生效。不同锁、不同对象的monitor，在JMM语义下就是两条平行线，永远不会有交集。
第三，检查volatile变量的使用是否满足"不依赖当前值"的条件。如果你写volatile int i; i++;，这在多线程下依然是错的，因为i++不是原子操作。
第四，检查复合操作的边界。如果一段逻辑要先读一个共享状态，再做计算，再写回共享状态，那么即使每个共享变量都标了volatile，整个"读-算-写"过程仍然不是原子的，需要锁或原子类来兜底。
第五，检查锁的粒度跟业务需求是否匹配。JMM不负责帮你判断粒度的合理性，但如果你在用锁保护一个根本不需要跨线程可见性的局部临时变量，那就是白白损失吞吐量。粒度选择主要靠对业务不变式的理解，JMM解决的是"用了锁是否安全"的问题。
这套清单在code review时特别管用。很多新人写并发代码，眼睛只盯着"有没有加锁"，却从不想锁对象是谁、可见性靠什么建立、原子性边界在哪。把JMM当检查工具，很多问题在第一遍review时就能被消灭，而不是等到线上出事故再定位。
再分享一个压测阶段的验证技巧：在测试环境，可以试着关闭JIT的部分激进优化（比如-XX:-EliminateLocks这类参数），人为弱化底层的优化行为，模拟更保守的执行语义。如果代码在这种环境下暴露出可见性或重排序相关的问题，那大概率说明某些共享变量的同步保障不完善。这种方法不适合生产环境长期开启，但作为验证手段，比靠肉眼在代码里找bug高效得多，我实测下来很稳。
我个人在实际排查中的体会是：遇到"偶发、复现不了、加锁无效"的并发问题，先别急着怀疑硬件和框架，回到JMM的规则表上，用最朴素的"这条读写路径上，存不存在happens-before关系"来提问。答案往往就藏在你没注意的那个共享变量上——它可能没加volatile，可能加错了锁对象，可能依赖了非线程安全的工具类。JMM说白了就是一张底层地图，有了它，并发问题不再是玄学，而是有据可依的逻辑推理题。
最后留一个小建议：不要创造性地发明并发同步方案，先学会把JMM规定的几种标准模型（锁内可见、volatile发布、不可变对象、线程间通信）用熟。绝大多数场景，标准模型都够用了。等你哪天真需要unlocked高性能路径时，再回过头从JMM的8种操作和内存屏障去设计自己的同步策略，也不迟。
