异常房间免安装绿色中文版
2.61G · 2025-09-20
作为一名Java开发者，你是否曾遇到过如下诡异的情景？这段代码在你的IDE里运行一段时间就会停止，但在生产环境的服务器上却可能永远停不下来。
public class NeverStop {
private static /*volatile*/ boolean stop = false; // 注意：这里没有volatile
public static void main(String[] args) throws InterruptedException {
new Thread(() -> {
while (!stop) { // 子线程无法"看到"主线程修改后的值
// 疯狂循环
}
System.out.println("Thread stopped.");
}).start();
Thread.sleep(1000);
stop = true; // 主线程修改共享变量
System.out.println("Main thread set stop to true.");
}
}
问题根源并非Java的BUG，而是源于现代计算机的硬件架构。为了充分压榨CPU性能，计算机会采用多级缓存、指令乱序执行等优化策略。这导致了同一个变量在多个CPU核心的“视角”下可能拥有不同的值。
Java内存模型（Java Memory Model, JMM） 就是一个为了屏蔽各种硬件和操作系统的内存访问差异，让Java程序在各种平台下都能达到一致的内存访问效果而提出的抽象规范。它定义了线程如何与主内存进行交互，是理解Java并发编程的基石。
本文将围绕JMM，从基础概念到高级特性，并结合实战案例，带你彻底攻克并发编程中的可见性、原子性和有序性问题。
JMM的主要目标是定义程序中各个变量的访问规则。它规定了所有变量都存储在主内存中。
它们之间的交互关系，可以用下图清晰地表示：
sequenceDiagram
participant MainMemory as 主内存
participant ThreadA as 线程A工作内存
participant ThreadB as 线程B工作内存
Note over MainMemory, ThreadA: 8种原子操作保障内存交互
rect rgb(240, 248, 255)
Note over MainMemory, ThreadA: 读取操作流程
ThreadA->>MainMemory: lock (锁定变量)
MainMemory->>ThreadA: read (读取值)
ThreadA->>ThreadA: load (载入工作内存)
ThreadA->>ThreadA: use (使用变量)
end
rect rgb(255, 242, 232)
Note over MainMemory, ThreadA: 写入操作流程
ThreadA->>ThreadA: assign (赋值给工作变量)
ThreadA->>MainMemory: store (存储到主内存)
MainMemory->>MainMemory: write (写入主内存)
MainMemory->>MainMemory: unlock (解锁变量)
end
Note over ThreadA, ThreadB: 线程间通信必须通过主内存
ThreadA->>MainMemory: store/write (写入)
MainMemory->>ThreadB: read/load (读取)
（JMM内存交互模型）
交互协议：JMM定义了8种原子操作来完成主内存与工作内存的交互：
| 操作名称 | 作用范围 | 功能描述 |
|---|---|---|
| lock (锁定) | 主内存变量 | 将变量标识为线程独占状态 |
| unlock (解锁) | 主内存变量 | 释放变量的锁定状态 |
| read (读取) | 主内存变量 | 将变量值从主内存传输到工作内存 |
| load (载入) | 工作内存变量 | 将read得到的值放入工作内存的变量副本中 |
| use (使用) | 工作内存变量 | 将工作内存变量值传递给执行引擎 |
| assign (赋值) | 工作内存变量 | 从执行引擎接收值，赋给工作内存变量 |
| store (存储) | 工作内存变量 | 将工作内存变量值传输到主内存 |
| write (写入) | 主内存变量 | 将store传输的值放入主内存变量中 |
JMM规定了这些操作的执行顺序和规则：
注意：read和load、store和write必须成对出现，但不必连续。中间可以插入其他指令，这就为重排序提供了可能。
在深入JMM的解决方案之前，必须了解一个底层概念——内存屏障（Memory Barrier），也称内存栅栏（Memory Fence）。它是理解volatile和锁如何工作的基石。
为什么需要内存屏障？ 编译器和CPU为了优化性能会进行指令重排序。这在单线程下无懈可击，但在多线程下会导致灾难。内存屏障就像是一个“刹车”，告诉编译器和CPU：在此处，某些类型的重排序必须停止！
内存屏障主要分为四种类型，几乎所有的并发同步机制都间接或直接地使用了它们：
| 屏障类型 | 指令示例 | 说明 |
|---|---|---|
| LoadLoad | Load1; LoadLoad; Load2 | 确保Load1的数据装载先于Load2及其后所有装载指令。 |
| StoreStore | Store1; StoreStore; Store2 | 确保Store1的数据刷新到主内存先于Store2及其后所有存储指令。 |
| LoadStore | Load1; LoadStore; Store2 | 确保Load1的数据装载先于Store2及其后所有存储指令。 |
| StoreLoad | Store1; StoreLoad; Load2 | 确保Store1的数据刷新到主内存先于Load2及其后所有装载指令。这是一个“全能型”屏障，开销最大。 |
JMM的作用：它通过在不同的字节码指令（如monitorenter/monitorexit、volatile读写）前后插入特定类型的内存屏障，来禁止特定类型的重排序，从而为开发者提供清晰的内存可见性保证。
JMM 是一个抽象模型，而它的很多设计灵感与约束，都来自于底层的硬件机制，其中最重要的就是缓存一致性协议。
现代CPU的多级缓存架构极大地提升了性能，但也导致了“数据副本”不一致的问题。为了解决这个问题，硬件设计者提出了一系列缓存一致性协议，其中最著名的是 MESI 协议。
MESI 是四种缓存行（Cache Line）状态的缩写，任何时刻一个CPU核心中的缓存行都处于以下状态之一：
CPU核心之间通过一个复杂的消息传递机制来维护这些状态，从而保证所有缓存中的数据副本最终保持一致。其交互过程可以通过以下状态机来表示：
stateDiagram-v2
direction LR
[*] --> I : 初始状态
I --> E: CPU发起写请求<br>缓存行不存在
I --> S: CPU发起读请求<br>其他缓存有或无(S状态)
I --> M: CPU发起写请求<br>缓存行不存在
E --> M: 本地CPU写
E --> S: 其他CPU读请求<br>状态变为共享(S)
M --> S: 其他CPU读请求<br>先写回内存再共享
M --> I: 其他CPU写请求<br>先写回内存再失效
S --> I: 其他CPU写请求<br>收到失效信号
S --> M: 本地CPU写<br>发送失效信号给其他缓存
note right of I
初始或已被丢弃
必须从主内存读取
end note
工作流程举例（简化的读/写交互）:
会议室白板比喻：我们可以把主内存比作公司服务器上的共享云文档，把每个CPU的缓存比作每个员工工位上的个人白板。
MESI协议的工作流程，就像一套员工之间协作更新白板和云文档的默契规则：
sequenceDiagram
participant CPU_A
participant CPU_B
participant Main Memory as 主内存 (云文档)
Note over CPU_A, CPU_B: 初始状态: 云文档 X=0
CPU_A ->> Main Memory: 读取 X (Read)
activate CPU_A
Main Memory -->> CPU_A: 返回 X=0
Note right of CPU_A: 我的白板: X=0 (状态:独占-E)
deactivate CPU_A
CPU_B ->> Main Memory: 读取 X (Read)
activate CPU_B
Main Memory -->> CPU_B: 返回 X=0
Note left of CPU_B: 我的白板: X=0 (状态:共享-S)
CPU_A -->> CPU_B: 嘿，我也有一份副本！
Note right of CPU_A: 状态降级为共享-S
deactivate CPU_B
Note over CPU_A, Main Memory: CPU_A 要修改 X=1
CPU_A ->> CPU_B: 发送“无效化”(Invalidate)消息
Note left of CPU_B: 收到！擦掉我白板上的X (状态:无效-I)
CPU_B -->> CPU_A: 确认无效化 (Ack)
CPU_A ->> CPU_A: 在自己的白板上修改 X=1
Note right of CPU_A: 状态升级为修改-M
CPU_B ->> Main Memory: 再次读取 X (Read)
activate CPU_B
CPU_A ->> Main Memory: 监测到请求，先将白板上的 X=1 <br>写回云文档 (Write-Back)
Note right of CPU_A: 状态降级为共享-S
Main Memory -->> CPU_B: 返回最新的 X=1
Note left of CPU_B: 我的白板: X=1 (状态:共享-S)
deactivate CPU_B
第一步：独占读取 (Read for Exclusive)
读请求。0，并记录在自己的缓存中。此时其他核心都没这个数据，所以CPU-A独占这份数据，状态变为E。第二步：共享读取 (Read for Share)
读请求。第三步：写入修改 (Write to Modified)
1。无效化消息，告诉所有其他缓存了X的副本（CPU-B）：“我要改了，你们的副本马上作废！”1，并将状态升级为M（修改）。此时，数据只存在于CPU-A的缓存中，且与主内存不一致。第四步：同步与再次共享
读请求。1）写回主内存；2) 将数据传给CPU-B。现在我们可以看到，MESI 协议已经在硬件层面解决了缓存一致性问题，那为什么还需要 JMM 和 volatile 呢？
原因在于 性能。CPU核心间发送“无效化”消息和等待响应是需要时间的（CPU 时钟周期）。如果CPU-A 在等待CPU-B 确认“无效化”的这段时间里什么都做不了，那将是对计算资源的巨大浪费。
为了解决这个性能问题，CPU 设计引入了 Store Buffer 和 Invalidate Queue：
正是这些硬件优化（Store Buffer, Invalidate Queue）的引入，导致了即使有MESI协议，依然会出现可见性和有序性问题。
而 JMM 的作用，就是通过在不同程序点（如 volatile 写、锁 释放）插入内存屏障，来告诉CPU：“在执行到这的时候，必须清空Store Buffer，处理Invalidate Queue，保证所有的读写操作都符合MESI协议的规定流程，不允许搞任何小动作（重排序和延迟失效）”，从而绕过这些异步优化带来的副作用，为程序员提供确定性的内存可见性保证。
原子性是指一个或多个操作要么全部执行成功，要么全部不执行，不会被打断。
案例：i++ 操作不是原子性的。它实际上分为三步：
read变量i到工作内存。i+1操作（use/assign）。store/write回主内存。如果两个线程同时执行i++，可能会出现交错执行，导致最终结果小于预期。
public class AtomicityDemo {
private int count = 0;
public void increment() {
count++; // 非原子操作
}
}
可见性是指当一个线程修改了共享变量的值，其他线程能够立即得知这个修改。
案例：本文开头的例子就是典型的可见性问题。线程1修改了stop的值，但未能及时刷回主内存，或者线程2未能及时从主内存更新自己的副本，导致线程2无法“看见”这个变化。
有序性是指程序执行的顺序按照代码的先后顺序执行。但为了性能，编译器和处理器会进行指令重排序。
案例：双重检查锁定（DCL）单例模式。
public class Singleton {
private static Singleton instance; // 错误写法，缺少volatile
public static Singleton getInstance() {
if (instance == null) { // 第一次检查
synchronized (Singleton.class) {
if (instance == null) { // 第二次检查
instance = new Singleton(); // 问题所在！
}
}
}
return instance;
}
}
instance = new Singleton(); 这行代码分为三步：
步骤2和3可能被重排序。如果线程A执行完1和3后被挂起，此时instance已非null但对象未初始化。线程B在第一次检查时看到instance非null，会直接返回一个未初始化完成的对象，导致程序错误。
解决方案：使用 volatile 禁止重排序。
private static volatile Singleton instance; // 正确写法
Happens-Before是JMM最核心的概念。它是一组规则，用于判断两个操作之间的内存可见性。如果操作A Happens-Before 操作B，那么A所做的任何更改对B都是可见的。
重要原则：
Thread.start()的调用Happens-Before于启动线程中的任何操作。join()中返回。Happens-Before关系并不等同于时间上的先后，它强调的是内存可见性的保证。
volatile是JMM提供的轻量级同步机制。它通过底层插入内存屏障来实现两大特性：
sequenceDiagram
participant MainMemory as 主内存 (volatile变量v)
participant ThreadA as 线程A工作内存
participant ThreadB as 线程B工作内存
Note over MainMemory: volatile变量保证可见性
ThreadA->>MainMemory: read v
MainMemory->>ThreadA: load v
ThreadA->>ThreadA: use v
Note over ThreadA: 线程A修改v
ThreadA->>ThreadA: assign v (新值)
ThreadA->>MainMemory: store v (立即刷新到主内存)
MainMemory->>MainMemory: write v
Note over MainMemory: 立即通知其他线程
MainMemory->>ThreadB: 使ThreadB的工作内存中v失效
ThreadB->>MainMemory: read v (重新读取最新值)
MainMemory->>ThreadB: load v (新值)
其内存屏障策略如下图所示，这直接对应了 volatile变量规则：
flowchart LR
subgraph VolatileWrite [Volatile 写操作]
direction LR
A[之前的写操作] --> B[StoreStore Barrier]
B --> C[Volatile Write]
C --> D[StoreLoad Barrier]
end
subgraph VolatileRead [Volatile 读操作]
direction LR
E[Volatile Read] --> F[LoadLoad Barrier]
F --> G[LoadStore Barrier]
G --> H[后续的读/写操作]
end
public class Singleton {
// 使用volatile关键字防止指令重排序
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;
}
}
在DCL单例中，volatile关键字至关重要，因为它解决了以下问题：
防止指令重排序：instance = new Singleton()这行代码实际上包含三个步骤：
如果没有volatile，步骤2和3可能被重排序，导致其他线程看到一个非null但未完全初始化的对象。
保证可见性：确保一个线程对instance的修改能立即对其他线程可见。
重要提示：volatile不保证原子性。对于复合操作（如count++），仍需使用synchronized或AtomicInteger等原子类。
synchronized 关键字是 JMM 提供的、功能最强大的同步原语之一。它直接对应着 JMM 中的 lock 和 unlock 操作，能够完整地解决并发三大问题，其底层实现同样依赖于内存屏障。
原子性 (Atomicity)：
synchronized 块或方法确保了一次只有一个线程可以执行被保护的代码段。这使得像 i++ 这样的复合操作在同步块内成为原子操作。可见性 (Visibility)：
monitorexit指令）时，JMM 会强制将该线程的工作内存中的修改刷新到主内存中。当线程获取锁（执行monitorenter指令）时，JMM 会使该线程的工作内存中的变量副本失效，从而必须从主内存重新加载共享变量。这个过程包含了内存屏障的使用。有序性 (Ordering)：
synchronized 保证了同一时刻只有一个线程执行同步代码（“串行”执行），因此在这个线程内部，代码是顺序执行的。代码示例：解决原子性和可见性
public class SynchronizedDemo {
private int count = 0;
// synchronized 保证 increment() 方法的原子性和可见性
public synchronized void increment() {
count++; // 原子操作，且修改对所有后续获取此锁的线程可见
}
public synchronized int getCount() {
return count; // 总能读取到最新值
}
}
synchronized 通过对象监视器 (Monitor) 实现其语义。每个 Java 对象都可以作为一个监视器，线程获取监视器的所有权后才能执行 synchronized 块中的代码。
当线程进入 synchronized 块时，会执行以下操作：
当线程退出 synchronized 块时，会执行以下操作：
JDK 1.6之后，synchronized 引入了锁升级机制：无锁 → 偏向锁 → 轻量级锁 → 重量级锁。这种优化减少了锁操作的开销，只有在真正竞争激烈时才会升级为重量级锁。
结论：synchronized 是 JMM 规范的一个直接且核心的实现，它通过锁的获取和释放操作，内置了强大的内存可见性、原子性和有序性保证。
final 关键字的行为在多线程环境下有着特殊的、由 JMM 规范保证的语义。它主要解决的是对象构造过程中的可见性和有序性问题，是一种免同步的解决方案。
JMM 为 final 域的写入和读取提供了特殊的 “初始化安全” 保证，这主要通过禁止特定重排序来实现。
禁止重排序：
final 域的写入（初始化），与随后将被构造对象的引用赋值给一个变量（比如 instance = new MyClass();），这两个操作不能被重排序。final 域的对象引用，那么这个 final 域必然已经被构造函数正确初始化了。这完美解决了 DCL 问题中可能遇到的未初始化问题。可见性保证：
final 域的对象，只要构造过程没有发生“this引用逸出”，那么当其他线程看到这个对象时，该对象的 final 字段的值一定是被构造函数写入的值，而不需要额外的同步。代码示例：初始化安全
public class FinalFieldExample {
final int x; // final 域，享受JMM的初始化安全保证
int y; // 普通域，不享受
static FinalFieldExample instance;
public FinalFieldExample() {
x = 42; // 1. 写入final域
y = 50; // 2. 写入普通域
}
public static void writer() {
instance = new FinalFieldExample(); // 3. 发布对象
}
public static void reader() {
if (instance != null) {
int a = instance.x; // 保证读到 42 (Thanks to JMM and final)
int b = instance.y; // 可能读到 0 (默认值) 或 50，无法保证
}
}
}
注意：final 字段的“初始化安全”保证有一个重要前提：在构造过程中不能发生“this引用逸出”。即在构造函数中不得将this传递给其他线程，否则仍可能看到未初始化完成的对象。
结论：final 是 JMM 提供的一种免同步的、隐式的内存可见性与有序性解决方案，但它有严格的适用范围——仅限于对象的构造阶段。它是实现安全发布和不可变对象的关键。
stop），且操作本身是原子的，使用volatile性能远高于synchronized。ConcurrentHashMap、CopyOnWriteArrayList等，它们使用了更细粒度的锁或无锁技术（如CAS）。AtomicInteger、LongAdder等，它们基于volatile和CAS，避免了互斥锁。| 问题类型 | 典型现象 | 排查工具与思路 |
|---|---|---|
| 可见性 | 程序行为不稳定，时而正确时而错误，数据不新鲜。 | 使用volatile或synchronized来验证猜想。使用jstack查看线程状态。 |
| 原子性 | 计数结果总是偏小，数据不一致。 | 检查是否存在i++等复合操作。使用原子类或同步块解决。 |
| 有序性 | 现象极其诡异，如DCL单例拿到未初始化对象。 | 检查是否存在指令重排序的可能。使用volatile关键字。 |
| 死锁 | 程序卡住，无响应。 | 使用jstack或jconsole查看线程堆栈，检测锁的持有和等待关系。 |
推荐工具：
Java内存模型（JMM）是Java并发编程的底层核心，它通过定义主内存、工作内存的交互协议，以及提供synchronized、volatile、Happens-Before规则等工具，来解决由于硬件优化带来的可见性、原子性和有序性问题。
| 特性 | volatile | synchronized | final (在JMM语境下) |
|---|---|---|---|
| 原子性 | 否 | 是 | 否 |
| 可见性 | 是（直接保证） | 是（通过锁规则） | 是（仅限于构造阶段） |
| 有序性 | 是（限制重排序） | 是（限制重排序+串行执行） | 是（禁止初始化重排序） |
| 机制 | 内存屏障 | 锁 + 内存屏障 | 禁止特定重排序 |
| 场景 | 状态标志、DCL | 安全的复合操作、临界区 | 安全发布、不可变对象 |
