1. 从一段"诡异"并发代码说起：JMM到底在解决什么问题
有段时间我负责维护一个老项目，线上偶发出现一个怪现象：某个配置开关明明已经在后台改掉了，但线上进程就是感知不到变化，非要重启或者等上几分钟才生效。当时资历尚浅，第一反应是"缓存没刷新"，但排查了一圈，发现业务代码里根本没有缓存层。后来才明白，真正的问题是并发可见性——另一个线程修改了变量，当前线程的工作内存里却还是旧值。这个问题的根源，就是JMM（Java内存模型）覆盖的范畴。
很多初学者会把JMM和JVM运行时内存区域搞混，以为JMM讲的是堆、栈、方法区怎么划分。这是完全两码事。JVM内存结构是描述"对象和元数据存在哪里"，而JMM描述的是"并发场景下变量的读写规则"。简单说，JMM是一套规范，定义了在多线程环境下，一个线程对共享变量的写入何时对另一个线程可见，以及编译器、JIT、处理器可以做怎样的指令重排序。这套规范足够抽象，上游屏蔽了不同CPU架构的缓存一致性差异，下游约束了编译器优化边界。
这篇文章是并发编程系统学习的第三章，前两章我们大概聊了线程生命周期和synchronized的基本用法，这一章把JMM这个"水下的冰山"拎出来，结合volatile、synchronized、final等关键字，以及happens-before规则，做一次彻底拆解。同时也把JMM和物理硬件模型、JVM运行时数据区、ThreadLocal做一个横向对比，帮大家把脑子里那团"并发知识"真正理顺。适合已经能写多线程Demo、但遇到线上诡异问题就摸不着头脑的开发者，无论你是校招刚入职还是工作两三年想补基础，都能从中找到可落地的认知升级路径。
2. 为什么需要一套"内存模型"：从硬件缓存到JMM的抽象
2.1 一个共享变量到底经历了什么
先想一个很基础的问题：在多核处理器上，两个CPU核心同时访问同一个内存地址，它们看到的值一定一样吗？
答案是不一定。
现代CPU为了弥补主内存和寄存器之间的速度差，在中间加了好几层高速缓存（L1、L2甚至L3）。每个核心都有自己专属的L1/L2缓存，一个变量被加载到缓存里之后再修改，如果没有特殊指令去"刷回"主内存，其他核心是看不到这个改动的。就算写回了主内存，其他核心缓存里的副本也未必会立刻失效。这就是CPU级别的"缓存一致性"问题。
硬件层面应对这个问题的方案有很多，比如各种缓存一致性协议（常见的比如MESI协议族），但是不同CPU厂商的实现细节不一样，指令集不一样。Java作为"一次编写、到处运行"的语言，不可能直接在语言规范里绑定某种CPU的具体行为，于是JSR-133专家组（就是制定Java内存模型的那群人）设计了JMM这套逻辑抽象层。
可以这么理解：JMM是Java对待并发内存可见性问题的一份"最低纲领"。它不要求所有平台实现方式完全一致，但要求最终的行为结果一致——只要一个程序在JMM规则下是正确的，它跑在任何架构的JVM上，结果都应该是正确的。
2.2 JMM的核心抽象：主内存与工作内存
JMM规定所有变量（这里指实例字段、静态字段、数组元素等共享变量，不包括局部变量和方法参数，因为它们是线程私有的）都存在主内存中。每个线程还有一个自己的工作内存，可以类比成线程私有的缓存副本。
线程对变量的所有读和写，都不能直接操作主内存。必须先把变量从主内存拷贝一份到工作内存，然后在线程自己的工作内存里进行操作，操作完成之后，再找某个时间点把新值刷回主内存。这个过程在JMM里定义得非常机械——不是"可能发生"，而是"必须遵守"。
画一个生活类比：工作内存就好比你的工位桌面，主内存好比部门公共文件柜。你要改文件柜里的一份文档，不能拿着笔蹲在文件柜前面写，你得先把文件拿出来放在工位上改，改完再放回去。关键问题是——你什么时候把文件放回去？放回去之后，隔壁工位的同事什么时候才能看到新版文件？如果A同事改完没放回柜子，B同事又从柜子里拿了一份旧版出来，那两个人手里的文件就完全对不上了。
这个类比里缺一个东西，就是"规则"：什么时机允许放回、什么时机必须放回、别人拿文件的时候什么情况下必须先去柜子刷新。JMM里定义那8种原子操作和happens-before规则，干的就是这件事。
2.3 JMM规定的8种原子操作
JMM定义了8种操作来支撑主内存和工作内存之间的交互协议，它们全部是原子的、不可再分的。虽然这些操作在实际Java代码里看不见摸不着，但理解它们能帮你从底层看透很多并发Bug的本质：
- read：从主内存读取一个变量，传输到工作内存。
- load：把read得到的数据载入工作内存的变量副本。
- use：把工作内存中的变量值传递给执行引擎。
- assign：把执行引擎计算得到的新值赋值给工作内存中的变量。
- store：把工作内存中的变量值传输回主内存。
- write：把store传输的值写入主内存变量。
- lock：作用于主内存变量，把它标识成一条线程独占状态。
- unlock：作用于主内存变量，释放独占锁。
这些操作配对出现，但中间可以插入其他操作。举个例子，read必须紧随load之前，store必须紧随write之前，但一对读写之间可以插入变量被use/assign的流程。换句话说，工作内存从主内存拿一份数据、然后改半天、再刷回主内存，这中间有充分的"时间窗口"可以让数据变得不一致。
JMM还规定了一些顺序性约束，比如不允许一个线程丢弃最近的assign操作（改完的值不能当没发生），不允许无原因地把工作内存中的数据刷回主内存（时机没到不能瞎刷），更不允许线程直接在主内存中修改变量。这些约束的目的只有一个：让"缓存不可见"的问题变成一种"有规律可循、可预测、可推理"的行为。
3. 三大并发特性的底层支撑
3.1 原子性：谁保证了一个操作不可打断
并发领域三个经典特性是原子性、可见性、有序性，JMM对这三个特性的支撑力度是完全不一样的。
原子性说的是"一个操作或者多个操作要么全部执行且不被干扰，要么全部不执行"。JMM直接保证的原子操作，就是刚刚那8种基础操作。但是业务代码里类似i++这样的复合操作，在JMM层面并不是原子操作——它至少包含读取i、计算i+1、写回i三个步骤，期间随时可能被其他线程插进来。
谁能扩展原子性的边界？答案是锁。synchronized块在字节码层面通过monitorenter和monitorexit保证了临界区代码的互斥执行，在JMM层面对应了lock和unlock操作。这也解释了为什么生产环境里统计类场景用AtomicInteger或LongAdder更合适——它们内部用CAS（比较并交换）配合volatile变量，把"读-改-写"压缩成一连串受控的原子指令，比用synchronized牺牲一点锁竞争、换来细粒度更小的冲突窗口。
有意思的是，JMM里有一个极少被提到但真实存在的规则：对于64位long/double类型，规范允许JVM把它们切分成两次32位读写来执行，理论上有非原子性风险。但主流HotSpot VM在实际实现中，把64位操作都实现为原子操作，所以绝大多数开发者感知不到。这个问题在面试里偶尔被翻出来当"冷知识"，但在工程实践中几乎不必担心。
3.2 可见性：为什么改了等于没改
可见性问题在开篇已经点出来了。JMM实现可见性的核心机制，是"变量修改必须沿着工作内存→主内存→其他线程工作内存"的路径传播。
普通共享变量不保证可见性，因为JMM没有规定线程什么时候把assign过的值刷回主内存，也没规定其他线程什么时候主动read主内存。这两个"没规定"就是数据不可见的温床。
volatile关键字的出现，就是为可见性提供了一个明确约束：volatile变量的写，必须在写完之后立刻store到主内存；volatile变量的读，必须先从主内存read最新值，再载入工作内存。换句话说，volatile变量不允许线程"私自缓存"。
synchronized也保证可见性，但机制不同——它是通过lock/unlock语义实现的：线程解锁之前，必须把工作内存中的修改全部刷回主内存；加锁之后，工作内存中的变量副本全部失效，后续读取必须从主内存重新load。所以锁不仅管互斥，还管"进门之前必须看最新版公告"。
3.3 有序性：编译器的小动作是如何被约束的
为了性能，编译器、JIT、CPU都可能对指令做重排序。单线程下，重排序不会改变程序的执行结果（as-if-serial语义），但多线程下就未必了。最经典的案例是双重检查锁定（Double-Checked Locking）里的"未初始化半成品"问题，这里我稍微展开讲一下，因为它比理论更能说明问题。
看这段广为人知的代码：
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; } }new Singleton()在字节码层面可以拆成三步：分配内存空间、调用构造器初始化所有字段、把引用地址赋给instance。如果不加volatile，JIT和CPU可能把第2步和第3步调换顺序。于是另一个线程在第一次检查时看到instance不是null，直接拿去使用，但此时构造器还没执行完，拿到的是一个"字段全是默认值"的不完整对象。
volatile在JDK 5之后（JSR-133重新修订了内存模型）具备一个核心能力：禁止对该变量周围的读写指令做重排序。具体来说，volatile写操作之前的普通读写不允许跑到写操作后面，volatile读操作之后的普通读写不允许跑到读操作前面。因此上面的双重检查锁才能成为安全写法。
从这里也能看出，有序性的核心不是"完全禁止重排序"，而是"在关键边界上划出禁飞区"。JMM用happens-before规则限制了重排序的边界，让并发程序的行为变得可以推理。
4. happens-before规则：八个最重要的并发"交通法则"
4.1 为什么有这条规则
happens-before是JMM定义的一种偏序关系，用来描述两个操作之间的内存可见性。A happens-before B，意思就是A的执行结果对B可见，且A的执行顺序在B之前（从内存可见性视角看）。
理解happens-before的关键，是不要把它理解成"时间先后"，而是要理解成"可见性保证"：只要满足happens-before关系，前一个操作写入共享变量的值，后一个操作一定能看到。
JMM给程序员提供了8条happens-before规则，日常写并发代码基本靠这几条就够了。
| 规则 | 含义 | 典型场景 |
|---|---|---|
| 程序次序规则 | 一个线程内，按代码顺序，前面的操作happens-before后面的操作 | 垂直代码逻辑天然成立 |
| 监视器锁规则 | 解锁操作happens-before后续对这个锁的加锁操作 | synchronized块内外的变量共享 |
| volatile变量规则 | 对一个volatile变量的写操作happens-before后续对该变量的读操作 | 标志位控制线程启停 |
| 线程启动规则 | 调用start()方法happens-before新线程内的任何操作 | 主线程new Thread后start |
| 线程终止规则 | 线程内所有操作happens-before其他线程检测到该线程终止 | Thread.join()返回后 |
| 线程中断规则 | 调用interrupt()方法happens-before被中断线程检测到中断事件 | isInterrupted()为true |
| 对象终结规则 | 对象构造函数执行完happens-beforefinalize()方法开始 | 对象被回收前 |
| 传递性 | 如果A happens-before B，B happens-before C，则A happens-before C | 链式推导可见性 |
4.2 几条规则组合出来的"实战配方"
单独一条规则看起来都很简单，但真正好用的是组合。我记得有个经验丰富的同事提过一句话："并发排查的第一件事，就是把代码里涉及的共享变量，对照这8条规则一条条找，看看能不能找到一条happens-before链。找到了，可见性就没问题；找不到，就是隐患。"
举个例子：线程A往普通HashMap里放数据，放到一半调用threadB.join()。根据线程终止规则，线程A之前的所有操作都happens-before join()的返回，而join()返回后线程B继续执行的代码，属于"后续操作"，再通过传递性，线程A往HashMap里放的数据对线程B可见。所以即使HashMap本身线程不安全，如果只在A填完数据后启动B去读，且中间没有写，那么读写并不存在数据竞争。这也是"线程安全"定义里经常被忽略的细节——同步手段不一定是锁，线程之间的协作机制本身也携带同步语义。
还有最常见的线程启停模式：用volatile布尔变量控制子线程退出循环。根据volatile变量规则，主线程修改flag之后，子线程在读取flag时必然看到最新值。这里很多人会问"volatile到底能不能替代synchronized"，答案是不能替代互斥，但能替代可见性。如果你的场景只是"一个线程改，另一个线程读，且读者不关心中间状态"，volatile就是合适的选择。
4.3 容易忽略的as-if-serial语义
讲到有序性就绕不开as-if-serial。它的意思是：不管怎么重排序，单线程程序的执行结果不能改变。这是编译器做优化的底线。
但在多线程程序里，"单线程视角"就不够了。A线程里执行了x=1，接着执行y=2，另一个线程依赖x和y的顺序，可能就会踩坑。因为编译器认为只要A线程自己看没问题就行，它不会主动考虑别的线程的视角。
所以我们在写并发代码时，要把"as-if-serial"忘掉，时刻记住"别人看到的不一定是我写代码的顺序"。唯一的例外就是happens-before规则覆盖的地方。
5. 对比剖析：JMM与硬件模型、JVM内存结构、ThreadLocal的分界线
5.1 JMM vs 硬件内存架构：抽象和实体的关系
很多文章把JMM工作内存直接类比成CPU缓存，这个类比能帮助理解，但别过度延伸。因为硬件层面的缓存一致性协议（比如MESI系列）在个体行为上比JMM要激进得多——它提供了比JMM更强的保证，但也更依赖硬件架构。
举个例子，x86架构下有比较强的缓存一致性保证，加上它的写缓冲（store buffer）机制，实际表现是：StoreLoad重排有可能发生，但LoadLoad和LoadStore几乎不会重排。因此在x86上实现volatile，只需要在volatile写之后加一条屏障指令，成本相对可控。
而一些弱内存模型架构（比如ARM、PowerPC）重排限制很宽松，编译器需要生成更复杂的屏障指令组合，才能真正实现JMM要求的语义。这也是为什么JMM必须做成"与具体硬件解耦"的抽象规范——它定义的是"必须满足的最弱保证"，具体到每个平台上，实现方可以做得更强，但不能更弱。
从工程视角看，这个对比带给我们一个启示：JMM不是让你去背内存屏障指令的，它是让你在写Java代码时不需要关心底层CPU细节。真正需要关心屏障的，是JVM的开发者。
5.2 JMM vs JVM运行时数据区：别再把它们混为一谈
这是我在指导新手时发现的高频认知误区。JVM运行时数据区指的是：程序计数器、虚拟机栈、本地方法栈、堆、方法区。这是从"内存哪里放什么"的角度看的，解决的是对象生命周期和回收管理问题。
JMM里的主内存和工作内存是"物理内存+缓存"的抽象模型，解决的是多线程读写共享变量时的正确性问题。两者不是一回事，也不需要一一对应。
如果非要找对应关系，可以粗略这么说：JMM中的主内存，在物理上主要对应堆内存中的变量存储区域；而JMM中的工作内存，物理上对应线程的寄存器、缓存，可能还包括一部分栈区域。但注意，这种对应只是为了建立直觉，不是严格的映射关系。
5.3 JMM工作内存 vs ThreadLocal：两个维度的"线程私有"
ThreadLocal也号称"线程私有副本"，很多初学者会把工作内存和ThreadLocal搞混。这里必须掰开揉碎讲清楚。
ThreadLocal的线程私有，是指每个线程都持有自己的ThreadLocalMap，线程A往ThreadLocal里放的值，线程B读不到。这是"对象级别的隔离"——它让你根本不共享同一个变量实例。
工作内存的线程私有，则是指每个线程从主内存copy来的共享变量副本是自己可见的，这个副本可能跟其他线程的副本不一致。这是"值级别的缓存副本"——共享变量还是那个共享变量，所有人的修改最终要回到同一个地方，只是中间会产生不一致窗口。
如果画个图辅助理解：ThreadLocal是"同样一个钥匙，每人一把锁，各锁各门"；JMM工作内存是"同一扇门，每人手里都有一把钥匙，但开门看到的东西可能新旧不一"。
两套机制解决的是不同层面的问题：ThreadLocal解决"参数透传和隔离"，JMM解决"共享变量的可见性与正确性"。实际项目中可以组合用，但别指望用ThreadLocal替代volatile或者synchronized。
5.4 volatile vs synchronized vs Atomic类：三者在JMM语义上的差异
展开对比这三个并发工具，是因为它们在不同维度补足了JMM的能力：
| 特性 | volatile | synchronized | Atomic系类 |
|---|---|---|---|
| 原子性 | 不保证复合操作 | 保证临界区互斥 | 基于CAS保证单操作原子 |
| 可见性 | 写后立即刷主内存，读前强制读取最新 | 解锁刷回，加锁失效副本 | 内部依赖volatile实现可见 |
| 有序性 | 禁止重排的边界 | monitorenter/monitorexit限制 | 内部封装的CAS指令具备原子性天然语义 |
| 适用场景 | 标志位、状态开关、发布不可变对象 | 复合操作、临界区 | 计数器、累加器、并发数据结构 |
| 成本 | 低 | 高（可能涉及操作系统层锁） | 中（循环CAS在高竞争下开销大） |
在Spring这类框架里，大量"配置开关"和"运行状态引用"的字段就是用volatile修饰的，因为它们的写频率很低、读频率高，volatile刚好贴合这种"发布-订阅"模型。而真正的复合变更，比如转账扣款这种"先校验后扣减再入账"的序列，必须用锁配合事务，volatile层面的可见性只是必要条件，不是充分条件。
6. 内存屏障与JVM实现的核心细节
6.1 为什么JMM规则落到实现里会需要"屏障"
JMM对语言层的约束是规则化的，但落实到JVM实现和CPU指令层面，靠的是内存屏障（Memory Barrier）。内存屏障是一类特殊指令，它的作用是限制它两侧的指令重排序，同时保证某些缓存的失效或刷回操作被执行。
JMM在逻辑上把屏障划分为四类：LoadLoad、LoadStore、StoreStore、StoreLoad。名字本身已经提示了限制关系：例如LoadLoad屏障，意思是屏障前的读操作不能在屏障后的读操作之后执行；StoreLoad屏障是四种里面开销最大的，因为它要求所有之前的写操作都刷到主内存，同时后续的读操作都从主内存重新取。
HotSpot VM在解释执行和JIT编译时，会根据目标平台插入对应的屏障指令。我们平时写Java代码感知不到，是因为JVM帮我们把这些细节全部封装好了。但如果做底层研究，比如用hsdis插件反汇编看JIT生成的机器码，就能清楚地看到volatile读写周围多出来的指令序列。
6.2 volatile和synchronized在实现上的不同套路
以常见的x86平台为例：volatile写操作，JIT编译后会插入StoreStore屏障再加一条带lock前缀的指令，或者直接使用某些带全屏障语义的写指令，这能保证写操作不会和后续读写乱序；volatile读操作，由于x86的强一致性，通常只需要保证读操作不提前即可，所以有时候读侧只依赖编译器级别的重排限制就够了。
synchronized则靠的是更重的监视器锁机制。HotSpot VM里存在锁升级路径：无锁→偏向锁→轻量级锁→重量级锁。轻量级锁通过CAS操作获取锁，重量级锁则依赖操作系统层面的互斥量。但不管哪一级锁，获取锁和释放锁的边界处都会插入类似屏障的语义，保证临界区内的修改对后续获得锁的线程可见。
经验之谈：排查并发问题时，不要一上来就怀疑JMM的某些冷门行为。99%的并发Bug来自业务代码没做同步控制，或者同步控制的范围没覆盖到共享变量，而不是JVM实现出了偏差。
6.3 final字段的特殊语义
final在JMM里有一席之地，是因为构造器安全发布问题。JSR-133增强了对final的保证：在构造器内对一个final字段的写入，与随后把这个构造好的对象引用赋值给某个外部变量，这两者之间不会重排序；同时，初次读到一个包含final字段对象的引用，与随后读这个final字段，也不会重排序。
这意味着只要对象正确构造（构造器里没有把this泄漏出去），final字段就可以安全地被发布到其他线程，不需要额外的同步手段。所以不可变对象配合final字段，是一种天然线程安全的设计模式：把对象的所有字段都标记为final，构造完成后不修改，配合不可变集合，就能绕开一大部分并发复杂度。
7. 常见问题与排查技巧实录
7.1 一张问题速查表
| 现象 | 根本原因 | 解决方向 |
|---|---|---|
| 改了共享变量，其他线程一直看到旧值 | 可见性缺失，变量未用volatile或未加锁 | 加volatile或synchronized |
| 双重检查锁拿到"半初始化"对象 | new对象重排序 + 未禁止重排 | 单例字段用volatile修饰 |
| 多个线程同时i++，结果小于预期 | 复合操作非原子 | 用AtomicInteger或synchronized |
| 明明加了锁，别的线程还是读到旧数据 | 读和写没有使用同一把锁 | 读写两侧同步块统一锁对象 |
| 启动线程后马上在主线程读子线程设置的值，读不到 | 缺少happens-before边界 | 让主线程通过join等待子线程完成 |
| long/double偶尔读出半个值（奇慢才见） | 极老JVM上64位写未原子化 | 升级JDK，或直接用原子类 |
7.2 线上排查的实操套路
遇到并发引起的诡异问题，我的排查顺序一般是这样：
第一步，先确定是不是真的并发问题。把线上的偶现问题尝试用多线程压测复现，如果单线程跑一万次都过，多线程一压就出问题，基本锁定。
第二步，把共享变量全部列出来，逐个问三个问题：有没有被多个线程写？有没有读写发生在不同的锁内？有没有用volatile？任何一个回答出问题，就往里面挖。
第三步，借助工具验证。实时线程状态用jstack，锁竞争和内存指标用jstat，GC日志打开。对于疑似可见性问题，可以考虑在测试环境用压测工具构造高强度竞争，再用Java的jtreg测试库里的并发压力测试思路套进去，让问题在可控环境里暴露。
如果连现场都抓不到，可以用"更保守"的策略：在怀疑的共享变量上加volatile（如果语义允许），或者在读写入口统一加同一把锁。很多时候，最朴素的修复方式反而是最稳妥的。
7.3 几个容易翻车的细节
细节一：synchronized锁对象的可见性。锁对象必须是一把全项目共享的"钥匙"，如果A线程锁的是自己new出来的Object，B线程锁的也是自己new出来的Object，那它们各锁各的，完全不互斥。锁的互斥性取决于锁对象是否同一个。
细节二：volatile只能保证单次读写的可见性，不能保证"读-改-写"复合操作。比如count++用volatile修饰，依然会丢更新。这就是为什么计数器要选AtomicInteger。
细节三：不要在构造器里启动线程。如果构造器里启动了一个线程，而该线程访问了正在构建的对象，就会发生this逸出。即使字段是final，如果逸出发生在构造完成前，JMM也不能保证安全性。
细节四：锁粒度要敢拆。synchronized是一个重量级工具，如果一个方法里有多个互不相关的共享变量，拆成多个锁对象或者改用读写锁、StampedLock，可以把并发度提上去。JMM的可见性保证不会因为锁拆细而失效，只要每个共享变量的读写路径都受同一把锁保护。
8. 写在最后：JMM这把钥匙打开的不只是并发的大门
从我这些年排查并发问题的经验来看，真正让一个开发者从"能写并发代码"进阶到"敢写并发代码"的转折点，往往就是彻底想通了JMM这几件事：主内存和工作内存到底在说什么，happens-before如何串起所有同步手段，以及volatile、synchronized、final各自在什么位置发力。
刚开始学的时候，我也觉得JMM太抽象、太理论，跟业务代码离得远。后来踩了几个线上坑，才明白这层抽象恰恰是为了让上层的"安全保证"跨平台成立。没有这层模型，你在x86上调通的高并发代码，换到别的架构可能就翻车。
如果你正在学习并发编程，我的建议是不要急着去背诵8条happens-before规则，而是先拿着这段经典代码去反复推演：什么情况下其他线程会看到什么值？然后对照规则，一步一步画出变量读写的happens-before链条。这个过程走通之后，再看volatile、synchronized的底层实现，会觉得顺滑很多。
最后分享一个小技巧：养成一个习惯，每次写完一段涉及共享变量的代码，都自己在心里做一次"JMM检查"——这个变量的每次修改和读取，能通过哪条happens-before规则串联起来？如果串联不出来，那它就是一颗潜在炸弹。坚持这个习惯半年，你写并发代码的"手感"会有明显质变。
