企业官网建设流程全解析

最近在排查一个并发场景的线上问题，我重新把Java 内存模型（JMM）相关的资料翻了个底朝天。说实话，面试里大家都把"JMM、可见性、happens-before"挂在嘴上，但真正遇到诡异 Bug 时，能用这套知识定位问题的人并不多。这篇属于"上篇"，我先把最核心的骨架讲透——从 CPU 缓存模型到 JMM 抽象，再到三大特性和 happens-before 规则，最后落到两个非常容易踩的认知坑上。

整个"上篇"适合这几类人：准备 Java 并发面试、想系统梳理 JMM 底层逻辑、或者已经写过不少多线程代码但总感觉"差点意思"的开发者。我会尽量用大白话把抽象概念拆开讲，也会给到能直接照着排查问题的思路，不搞那种背完就忘的"八股文"。

1. 为什么先聊硬件：CPU缓存模型是JMM的出发点

1.1 从一次"诡异"的并发BUG说起

之前有个同事负责一个订单通知服务，核心逻辑是后台线程轮询消息队列，把推送任务交给 HTTP 客户端发出去。线上偶尔会出现"通知中断但进程还没死"的情况，日志里看不出任何异常，就像后台线程凭空消失了一样。

查了半天，最后定位到一个很常见的布尔标志位：

// 提供停止能力的服务 public class PushService { private boolean stopped = false; public void stop() { stopped = true; } public void work() { while (!stopped) { // 拉取消息并推送 } } }

线程 A 调用stop()把stopped置为 true，线程 B 正在执行的while (!stopped)却一直读到 false，循环永远不退出。这不是什么玄学，而是很典型的可见性问题——线程 B 没有及时看到线程 A 对共享变量的修改。

这类问题在本地开发环境很难复现，因为单机单核、代码少、JIT 优化不激进时，线程之间"碰巧"能通过主内存拿到最新值。但上了线上，多核 CPU、高负载、JIT 编译一跑起来，问题就藏不住了。所以想理解 JMM，必须先搞懂硬件层面发生了什么。

1.2 三级缓存与缓存一致性：CPU 怎么保证"大家看到同一份数据"

现代 CPU 为了弥补内存访问速度和计算速度之间的鸿沟，普遍采用多级缓存：

• L1 Cache 最靠近 CPU 核心，访问延迟极低，但容量很小，通常几十 KB。
• L2 Cache 稍大一些，每个核心独享或两两共享。
• L3 Cache 更大，多核共享。

无论缓存分几级，核心问题都一样：不同 CPU 核心各自持有同一份内存数据的副本，当一个核心修改了副本，其他核心怎么知道数据已经变了？

硬件层的答案是缓存一致性协议，最常见的比较经典的是 MESI 协议。它把缓存行的状态抽象为 Modified、Exclusive、Shared、Invalid 四种，核心之间通过总线嗅探机制传递状态变更。简单说，一个核心修改了某缓存行并回写后，其他核心中对应的缓存行会被标记为 Invalid，下次读取必须重新从主内存加载。

怎么理解这件事？你可以把共享变量想象成会议室白板上写的一个数字，每个参会人都默默在自己草稿纸上抄了一份。一个人走上台改写了白板上的数字，如果其他人不抬头看一眼白板，他们手里的草稿纸就还是旧数字。CPU 缓存就是这个"草稿纸"，主内存就是这个"白板"。

问题在于，"抬头看一眼白板"是有代价的——需要同步、需要总线通信、需要失效处理。CPU 为了性能，并不会每次读变量都跑去主内存。于是单靠硬件缓存一致性协议，依然无法完全解决多线程环境下的数据一致性问题，这就需要软件层面的内存模型来定义"什么时候必须抬头看白板"。

1.3 指令重排与 as-if-serial 语义：你以为的顺序并不等于执行顺序

比缓存一致性更隐蔽的问题，是指令重排。

编译器和 CPU 为了提升执行效率，只要不改变单线程语义，就可能把代码顺序打乱。一个经典例子：

int a = 1; // 操作1 int b = 2; // 操作2 int c = a + b; // 操作3

操作1和操作2谁先执行，对最终结果没有影响，CPU 就可能先执行操作2再执行操作1。这就是重排序，它受 as-if-serial 语义保护——无论如何重排，单线程程序的执行结果必须和按代码顺序执行的结果一致。

但多线程环境下，这种"不影响单线程结果"的重排可能影响另一个线程的判断。比如有一组指令：

// 线程1 config = loadConfig(); // 1. 加载配置 initialized = true; // 2. 标记配置已就绪 // 线程2 while (!initialized) { /* 等待 */ } useConfig(config); // 3. 使用配置

如果编译器或 CPU 把指令1和指令2颠倒过来，线程2看到initialized == true时，config可能还没被赋值，拿到的就是一个空对象或旧值。这种问题，光靠"加锁"能挡住一部分，但对于读多写少的场景，我们需要更轻量的同步手段。这也是 Java 引入了volatile关键字来禁止特定重排的原因之一。

可以说，Java 内存模型的出发点，就是要在"执行效率"和"正确性"之间划一条清晰的界线，让程序员知道：在什么情况下代码可以对另一个线程可见，什么时候允许 JVM 自由优化。

2. JMM核心抽象：主内存与工作内存

2.1 抽象模型：每个线程都有一张"草稿纸"

Java 内存模型本身是一套抽象规则，并不等同于实际的 CPU 缓存或物理内存布局。它定义了两个核心区域：

• 主内存：所有共享变量都存储在主内存中，对应概念上的"共享区域"。
• 工作内存：每个线程持有自己的工作内存，保存了线程用到的变量的副本。线程不能直接操作主内存中的变量，只能把主内存的值拷到工作内存，再在工作内存中读写，然后刷回主内存。

继续用白板和草稿纸的类比：主内存是那面白板，工作内存就是每个人手里的草稿纸。不同线程之间不能直接互相"传纸条"，所有信息交换都必须经过白板完成。

这套抽象虽然简单，却足以解释大量并发问题：

• 为什么线程 A 改了变量，线程 B 看不到？因为线程 B 还在读自己工作内存里的旧副本。
• 为什么加了synchronized能解决？因为进入同步块会强制刷新工作内存，退出同步块会强制把修改写回主内存。
• 为什么volatile能解决？因为读 volatile 变量时，JMM 要求必须从主内存取最新值；写 volatile 变量时，要求立即刷回主内存。

理解这套抽象，比死记"volatile 保证可见性"更本质。你能在脑海中画出一张图：读操作从主内存拉数据，写操作推数据回主内存，同步机制控制什么时间点允许"拉"和"推"。

2.2 volatile 与内存屏障：一句话说清它到底做了什么

网上讲 volatile 的文章很多，结论不外乎两条：保证可见性、禁止指令重排。但很多人不理解它底层怎么做到的，面试被追问就卡壳。

在 JMM 层面，volatile 的读写操作会插入特定的内存屏障，内存屏障相当于一条"关卡指令"，它禁止屏障两侧的指令越过关卡重排，同时强制对缓存一致性做出协调动作。HotSpot 实现里，volatile 写之前会插入 StoreStore 屏障，写之后插入 StoreLoad 屏障；volatile 读之后会插入 LoadLoad 和 LoadStore 屏障。

这些名字不用背，你只要记住一个核心感受：volatile 变量就像"公共白板上的重点标记"，每次读都强制看白板，每次写都强制更新白板，并且不让编译器随便调整跟它相关的代码顺序。

但 volatile 不是万能的。它不保证原子性，比如多个线程同时对 volatile 变量做count++，依然会丢失更新。为什么？因为count++本质是"读、加一、写回"三步，volatile 只能保证每一步都看到最新值，但不能保证这三步作为一个整体不被其他线程打断。所以 volatile 的典型应用场景是：一个线程写、多个线程读的标志位，或者作为"发布安全不可变对象"的引用。

2.3 原子性、可见性、有序性：三兄弟怎么配合

并发编程的三大特性，在 JMM 下各有各的保障手段：

这里有一个常见误区：很多人以为加synchronized只是为了互斥，其实它同时解决了可见性和有序性。进入 synchronized 块之前，JMM 会要求线程清空工作内存中相关变量，从主内存重新读取；退出 synchronized 块时，把工作内存中的修改刷回主内存。所以同步块内部的操作，对于"同一个锁"保护的后续代码是全局可见的。

而final字段也有自己的可见性保证：在构造函数中设置 final 字段之后，其他线程看到该对象的引用时，final 字段必然是初始化之后的值，不会被重排到构造函数之外。这也是为什么不可变对象天然适合做并发共享。

三大特性不是孤立的，实际编码时要一起考虑。比如单例双重检查锁时，如果你只用synchronized而不用volatile，依然可能因为指令重排导致另一个线程拿到"未完全初始化"的对象。这就是可见性和有序性同时被破坏的例子，后面第 3 章有机会再展开。

3. happens-before原则：判断并发安全性的"标尺"

3.1 八条规则分组背，不再怕面试官

JMM 规范给出了 happens-before 规则，作为判断两个操作之间是否存在时序保证的依据。如果操作 A happens-before 操作 B，那么 A 的结果对 B 可见，并且 A 的执行顺序在 B 之前。

八条规则，按记忆难度我分成三组：

第一组，基础规则：

1. 程序次序规则：一个线程内，书写在前的操作 happens-before 书写在后的操作。
2. 传递性：A happens-before B，B happens-before C，则 A happens-before C。

第二组，同步相关规则：

3. 管程锁定规则：对一个锁的 unlock happens-before 后续对这个锁的 lock。
4. volatile 变量规则：对一个 volatile 变量的写 happens-before 后续对这个变量的读。

第三组，线程生命周期相关规则：

5. 线程启动规则：Thread 对象的start()happens-before 该线程中的任何动作。
6. 线程终止规则：线程中的所有操作 happens-before 其他线程对该线程的终止检测（比如join()返回）。
7. 线程中断规则：对线程的interrupt()调用 happens-before 被中断线程检测到中断事件发生。
8. 对象终结规则：一个对象的构造函数结束 happens-before 该对象finalize()方法的开始。

提示：八条规则不要死记，要理解每一组背后解决什么问题。基础规则是前提；同步规则是并发代码最常用的"契约"；生命周期规则帮你判断线程间协作时的可见性。

3.2 用 happens-before 推导一段真实代码

单纯列规则没有说服力，我们用一段代码实际推导一遍。

// 线程1 config = loadConfig(); // 操作A ready = true; // 操作B，ready是volatile变量 // 线程2 if (ready) { // 操作C，读取volatile变量 useConfig(config); // 操作D }

我们来推导：根据 volatile 变量规则，操作 B（写 ready）happens-before 操作 C（读 ready）。根据程序次序规则，在线程1内部，操作 A happens-before 操作 B。根据传递性，操作 A happens-before 操作 B happens-before 操作 C happens-before 操作 D，所以线程2在ready == true时调用useConfig(config)，一定能看到线程1加载好的完整配置。

这里最容易被忽略的是"传递性"带来的连锁保证。很多文章只会说"volatile 保证可见性"，但为什么 volatile 能顺带保证其他普通变量的可见性？答案就在这条推导链路里：因为 volatile 变量读写形成了一个"同步点"，它前面的普通写操作借着传递性也获得了可见性保障。

3.3 实际开发中的应用：用它自查代码是否安全

我自己的习惯是，写完一段并发代码，先不用急着运行，拿八条规则逐个检查一遍时序关系。具体步骤如下：

• 找出所有"写共享变量"和"读共享变量"的地方。
• 看有没有哪条 happens-before 规则能建立读写之间的顺序。
• 如果找不到任何规则，这个共享变量的读写就有安全隐患，必须加同步或改用 volatile。
• 如果找到了，再顺着规则检查，另外弄清楚规则覆盖的是不是"所有执行路径"。

举个实际例子，生产环境很常见的"优雅停机"实现：

public class GracefulShutdown { private volatile boolean running = true; public void shutdown() { running = false; // 写volatile变量 } public void run() { while (running) { // 读volatile变量 // 业务逻辑 } } }

shutdown()和run()之间靠 volatile 规则建立 happens-before 关系。只要shutdown()先执行，run()里的循环就能看到最新值。但如果running不加 volatile，这条规则就不成立，程序就可能陷入死循环。

遇到更复杂的同步逻辑，就查 lock/unlock 规则、线程启动规则等。这套自查流程，比起凭感觉加锁要靠谱得多，也能显著减少并发 Bug 的反复排查成本。

4. 从JMM到JVM：工作中的应用与常见认知坑

4.1 停止线程为什么一定要用 volatile 或 Lock：经典死循环复盘

回到开头那个订单推送服务的案例。为什么本地测试没事，线上就不停不下来？原因可能有三层：

第一层，硬件层面。现代多核 CPU 架构下，不同核心各自持有变量的缓存副本，线程 B 一直在自己的工作内存中读stopped，根本不感知主内存的变化。

第二层，JIT 层面。热点代码被 JIT 编译后，如果编译器认为这个变量在循环体内没有被修改，可能直接把while (!stopped)优化成"读取一次标志位，之后永远用寄存器中的旧值"，循环变成真正意义上的死循环。

第三层，JMM 层面。stopped没有 volatile 修饰，也没有其他 happens-before 规则保证线程 A 的写对其他线程可见，所以线程 B 的行为没有被规范约束。

正确写法很简单：

private volatile boolean stopped = false;

这样既避免 JIT 把循环条件优化成常量，又保证了线程 A 的修改在线程 B 读取时立即可见。

另外提一句，如果你用一个 boolean 标志位做不到精确控制，可以考虑Thread.interrupt()。中断机制配合线程中断规则，天然有 happens-before 保证，不需要额外加 volatile。很多老手偏爱 interrupt 而不是自研标志位，这是有 JMM 依据的。

4.2 别再搞混 JMM 和 JVM 运行时数据区：顺带回答"Java 8 还有没有方法区"

这是面试和日常沟通中最容易混淆的两个概念。

• JMM（Java 内存模型）是一个并发正确性的抽象模型，讨论的是"线程如何通过主内存交换数据"、"什么操作对什么线程可见"，跟堆、栈没有直接关系。
• JVM 运行时数据区讨论的则是进程内内存的分区结构：堆、虚拟机栈、本地方法栈、程序计数器、方法区（以及它的实现元空间）。

很多人问："Java 8 的 JVM 内存模型里还有没有方法区？"这个问题的措辞其实就有歧义。准确说：方法区是 JVM 规范中的一个逻辑区域，Java 8 里它仍然存在，但 HotSpot 实现发生了变化——永久代（PermGen）被移除，改由元空间（Metaspace）来实现方法区，元空间不再占用堆内存，而是使用本地内存。所以严格来讲，规范层面方法区还在，只是实现方式和内存位置变了；而"永久代"这个实现概念在 Java 8 中确实没有了。

那 JMM 和 JVM 内存区域有关系吗？有，但间接。比如new出来的对象放在堆里，而线程对对象字段的访问受 JMM 约束；再比如方法区中的类元数据如果被多个线程同时加载，也要靠 JMM 保证安全发布。理解不到这一层，就容易把"堆内存溢出"和"并发不可见"混为一谈。

4.3 锁消除、锁粗化与内存模型的关系，以及下篇预告

JVM 在运行时还会做一些针对锁的优化，理解这些优化需要回头再看 JMM。HotSpot 里有几个比较典型的：

• 锁消除：JIT 分析发现加锁对象只被当前线程访问，就会把锁直接去掉。比如局部变量加synchronized，实际上没有任何并发竞争。
• 锁粗化：如果代码里对同一个对象连续加锁、解锁，JIT 会把锁的粒度扩大，减少反复锁定的开销。
• 偏向锁、轻量级锁：在不同竞争级别下，锁对象会从偏向锁逐渐膨胀为重量级锁，本质都是在 JMM 保证不被破坏的前提下尽量减少同步带来的性能损失。

这些概念在"上篇"里点到为止，因为它们需要先理解 JMM 的底层规则，不然只会背名词。下一篇我计划重点展开：volatile 内存屏障的源码视角、synchronized 的 Monitor 与对象头、final 字段的安全发布语义、以及如何用这些知识定位实际线上的并发问题。毕竟，内存模型这种底层知识，光有理论不落到排查手段上，还是空中楼阁。

最后说一句个人体会。学 JMM 最忌讳的是直接背结论，然后面试时把结论丢出来，却对"为什么"两眼一抹黑。我建议踩过并发坑的朋友都自己做一个小实验：写一个双线程共享变量循环，对比加不加 volatile 的运行差异；再写一个双重检查锁单例，试着自己用 happens-before 规则推导一遍安全顺序。把这两步做完，你对 JMM 的理解会比我见过的很多面试者要扎实得多。