JMM 内存模型：happens-before 八条规则全解

先给你一个 30 秒版答案，后面每一站都在给这句话"上细节"：

在日常工作中，JMM 是你写的每一行并发代码的"交通规则"：synchronized、volatile、ReentrantLock、线程池、CompletableFuture……这些工具的正确性，全部建立在这套规则之上。

本文的路线图：

• 主内存与工作内存 —— JMM 的抽象架构（第 2 站）
• 为什么需要 JMM —— 各 CPU 内存模型不一致，需要统一交规（第 3 站）
• 8 大原子操作 —— 主内存/工作内存的交互协议（第 4 站）
• 可见性、原子性、有序性 —— 并发三大问题（第 5 站）
• 指令重排序 —— 编译器与 CPU 的"自作主张"（第 6 站）
• happens-before 八条规则 —— JMM 的核心法则（第 7–10 站）
• 内存屏障 —— volatile 背后的硬件机制（第 11–12 站）
• final 域语义 —— 免同步的"安全通道"（第 14 站）
• JMM vs JVM 内存模型 —— 澄清最常见的概念混淆（第 16 站）

JMM 在逻辑上把内存划分为两个区域：主内存（Main Memory）和工作内存（Working Memory）。

• 主内存：所有线程共享，存放所有变量（实例字段、静态字段、数组元素）
• 工作内存：每个线程私有，是主内存中变量的本地副本（类比 CPU 缓存）

线程对变量的所有操作（读/写）都必须在自己的工作内存中进行，不能直接操作主内存。这就意味着：

1. 读变量：从主内存拷贝到工作内存 → 使用
2. 写变量：在工作内存中修改 → 刷回主内存

问题在于——刷回的时机不确定。如果一个线程修改了变量但没有及时刷回主内存，或者另一个线程没有从主内存重新加载，就会出现"看不到"的情况。

面试官如果追问一句"JMM 是怎么来的"，你要能答出背后的硬件现实：现代 CPU 为了性能，普遍做了三件"越界"的事——

• 写缓冲区（Store Buffer）：写操作先进缓冲区，稍后再落缓存/内存，导致"别人看到旧值"；
• 乱序执行（Out-of-Order Execution）：CPU 发现指令间没有数据依赖，就提前执行后面的指令；
• 多级缓存：L1/L2/L3 各自为政，缓存一致性协议只能解决"缓存行"级别的一致。

更要命的是，不同架构的"宽松程度"完全不同：

同一段 Java 代码，不加任何同步，在 x86 上可能"碰巧能跑对"，搬到 ARM 服务器（手机、云上 ARM 实例）上就出并发问题。怎么办？两个方案：

• 方案 A：为每个架构各写一套代码——维护成本爆炸，且 Java 号称"一次编写，到处运行"；
• 方案 B：在语言层面定义一套统一的内存模型，由 JVM 负责把它翻译成各架构需要的屏障——这就是 JMM 的定位。

一段不得不说的历史：JSR-133

JMM 不是一开始就这么完善。Java 5 之前的内存模型（旧 JMM）有三大硬伤：volatile 语义太弱（不能阻止重排）、final 字段没有任何可见性保证、happens-before 规则残缺。结果是 DCL（双重检查锁）在旧模型下是错的、final 字段可能看到默认值——全是著名大坑。2004 年，JSR-133 正式重写了内存模型（JLS 第 17 章），确立了以 happens-before 为核心的新体系，这些坑才被系统性修复。所以"JDK 5 之前 DCL 不靠谱"这种说法，根源就在 JSR-133。

为了规范主内存和工作内存之间的数据搬运，JMM 定义了 8 种原子操作（Atomic Operations）——所谓"原子"，就是这 8 个动作每一个都不可再拆分：

// 主内存操作：
lock      → 锁定主内存中的变量（标识为线程独占）
unlock    → 解锁主内存中的变量
read      → 从主内存读取变量值（传输到工作内存）
write     → 将工作内存的值写入主内存

// 工作内存操作：
load      → 将 read 得到的值放入工作内存副本
store     → 将工作内存的值传送到主内存（配合 write）
use       → 将工作内存的值传递给执行引擎
assign    → 将执行引擎的值赋给工作内存变量

一次完整的变量读取：read → load → use；一次完整的变量写入：assign → store → write。问题就出在 assign 到 write 之间存在不确定的延迟——赋值早已发生在工作内存，但什么时候 store + write 刷回主内存，JMM 不保证。

lock / unlock 正是 synchronized 在 JMM 层面的对应物：进入同步块时对锁对象执行 lock，退出时执行 unlock。unlock 之前的所有写操作必须已刷回主内存，lock 之后的所有读操作必须重新从主内存加载——这就是"解锁的写对加锁的读可见"的底层来源（第 8 站规则 2）。

JMM 的存在就是为了解决多线程的三大问题。每一种都有经典的代码案例——面试让你"手写一个并发 Bug"，这三个就是现成模板。

1. 可见性（Visibility）：一个线程的修改，另一个线程看不到

根源：工作内存未及时同步。典型场景就是第 1 站的"开关不生效"。

class VisibilityDemo {
    static boolean flag = false;
    static int number = 0;

    // Thread-1
    static void writer() {
        number = 42;    // 写入
        flag = true;    // 标志位
    }

    // Thread-2
    static void reader() {
        if (flag) {              // 看到了 flag=true
            System.out.println(number);  // 但 number 可能还是 0！
        }
    }
}

即使 Thread-2 看到 flag=true，也可能看到 number=0——因为指令可能被重排序，或者 number 还没从工作内存刷回主内存。

2. 原子性（Atomicity）：复合操作中间被打断

根源：读-改-写不是一步到位的。

class Counter {
    static int count = 0;
    // i++ 实际是三步：read → increment → write
    static void increment() { count++; }

    public static void main(String[] args) throws Exception {
        Thread[] threads = new Thread[100];
        for (int i = 0; i < 100; i++) {
            threads[i] = new Thread(() -> {
                for (int j = 0; j < 1000; j++) increment();
            });
            threads[i].start();
        }
        for (Thread t : threads) t.join();
        System.out.println(count);  // 期望 100000，实际 < 100000
    }
}

100 个线程各加 1000 次，期望 100000，实际往往差一截——因为两个线程可能同时读到 count=0，各自加 1 写回，一次递增被"吞"掉了。

3. 有序性（Ordering）：执行顺序和代码顺序不一样

根源：编译器和 CPU 的重排序。这是最能考倒人的一个，第 6 站单独展开。

class ReorderDemo {
    static int a = 0, b = 0;
    static int x = 0, y = 0;

    public static void main(String[] args) throws Exception {
        Thread t1 = new Thread(() -> { a = 1; x = b; });  // 可能被重排为 x=b; a=1;
        Thread t2 = new Thread(() -> { b = 1; y = a; });  // 可能被重排为 y=a; b=1;
        t1.start(); t2.start(); t1.join(); t2.join();
        // 理论上 x=0, y=0 是可能出现的！
    }
}

逻辑上不可能同时 x=0 且 y=0（总有一个线程先写），但重排序后它真的会出现——这就是面试里著名的"0,0 结果"问题。

三大问题，各由谁负责？

重排序（Reordering）是"程序写的是 A、B，实际执行可能是 B、A"。它可能发生在三个层面：

但重排序不是随心所欲的，它有一条铁律：不能破坏数据依赖（Data Dependency）。

把这两张表放一起，你就理解 ReorderDemo 为什么能出现 x=0, y=0 了：a=1 和 x=b 之间没有数据依赖，编译器/CPU 有充分的理由交换它们。

as-if-serial：单线程的"遮羞布"

不管怎么重排，单线程程序的执行结果不能被改变，这叫 as-if-serial（似串行）语义——"好像"是按顺序执行的。编译器和 CPU 只对单线程负责，把"结果一致性"兜住；多线程的正确性，需要程序员自己用 happens-before 关系来保证。

可以，但很看运气。用 -XX:+PrintAssembly 看汇编能看到重排痕迹；想稳定复现"0,0 结果"通常要循环跑几万次加上 CPU 压力。更实用的验证工具是 jcstress（OpenJDK 官方的并发压力测试框架），专门用来验证并发正确性——JMM 相关的测试和生产级并发库都在用它。

JSR-133 之后，JMM 描述可见性的主模型不再是 8 个原子操作，而是 happens-before（先行发生）关系。它回答一个问题：线程 A 的写入，什么时候能保证线程 B 一定看得到？

注意一个关键 nuance：happens-before 是"逻辑顺序保证"，不是"物理时间先后"。JMM 并不要求 A 真的先于 B 在时间上执行完，它只保证"如果 B 看到了 A 的结果，那么 A 写的一切都对 B 可见"。这给编译器和 CPU 留出了重排空间——只要重排不破坏 happens-before 关系，就随便优化。

happens-before 一共八条规则，分三组理解：

规则 1：程序顺序规则（Program Order Rule）

同一个线程内，前面的操作 happens-before 后面的操作。注意前提是同一线程——跨线程这条规则立刻失效。

int a = 1;   // A
int b = 2;   // B
// 单线程内：A happens-before B
// 编译器/CPU 可以重排，但必须保证单线程结果一致（as-if-serial）

规则 2：监视器锁规则（Monitor Lock Rule）

对同一把锁的 unlock 操作 happens-before 后续的 lock 操作。关键词是"同一把锁"——锁对象不同，规则不成立。

class SyncExample {
    int value = 0;
    synchronized void set(int v) { value = v; }   // unlock happens-before...
    synchronized int get() { return value; }       // ...后续 lock
}
// Thread-1 调用 set(42) → unlock
// Thread-2 调用 get()  → lock → 一定看到 42

生产里最常见的错误：写方法加了锁、读方法没加锁（或者两把不同的锁）。这时候规则 2 根本不成立——读线程可能看到旧值。所以"加锁要成对、锁对象要一致"，这是代码评审时一眼就能抓的问题。

规则 3：volatile 变量规则（Volatile Variable Rule）

对 volatile 变量的写操作 happens-before 后续对该变量的读操作。

volatile boolean ready = false;
int data = 0;

// Thread-1
data = 42;          // A
ready = true;       // B (volatile write)

// Thread-2
if (ready) {        // C (volatile read) → B happens-before C
    print(data);    // 一定看到 42（借助传递性：A→B→C）
}

这正是第 1 站事故的解法：把 flag 声明成 volatile boolean，配置下发后所有线程立刻能看到。volatile 最经典的用法就是一写多读的状态标志（服务停止开关、配置开关）。

规则 4：线程启动规则（Thread Start Rule）

Thread.start() 调用 happens-before 被启动线程中的任何操作。也就是说：主线程在 start 之前写的一切，子线程一进来就都能看到，不需要任何同步。

int config = loadConfig();     // 主线程先准备好
Thread worker = new Thread(() -> {
    // 这里一定能看到 config 的值
    // start() happens-before 此线程中的任何操作
    process(config);
});
worker.start();  // 这个调用 happens-before worker 线程内的所有代码

生产落点：给子线程传初始化好的配置、上下文、连接，靠 start 规则就够，不用画蛇添足加 volatile。同样，线程池 execute() 提交任务也有类似保证：任务提交 happens-before 任务开始执行（JUC 内部通过 AQS 的 volatile state 实现发布）。

规则 5：线程终止规则（Thread Join Rule）

线程中的所有操作 happens-before 其他线程成功从该线程的 join() 返回。

Thread worker = new Thread(() -> {
    result = compute();  // 计算结果
});
worker.start();
worker.join();          // join 返回后
print(result);          // 一定能看到 worker 线程中写入的 result

生产落点：主线程等一批子线程跑完再汇总，join() 返回后直接读结果就是安全的，不需要额外的锁或 volatile。这也解释了为什么 Future.get() 返回后能安全读取任务结果——底层正是同一套发布语义（AQS 的 state 写入 + 读取）。

规则 6：线程中断规则（Thread Interrupt Rule）

对线程 interrupt() 的调用 happens-before 被中断线程检测到中断事件。

Thread t = new Thread(() -> {
    while (!Thread.currentThread().isInterrupted()) {
        // 当 interrupt() 被调用，isInterrupted() 一定返回 true
        // interrupt() happens-before isInterrupted() 检测到中断
    }
});
t.start();
t.interrupt();  // 中断信号一定对目标线程可见

生产落点：优雅停机的推荐姿势就是"interrupt + 线程内检查中断标志"，比"共享 boolean 停止标志"更规范（sleep/wait 时还能自动抛中断异常退出阻塞）。注意 interrupted()（静态，会清除标志）和 isInterrupted()（实例，不清除）的区别——写循环条件时用后者。

规则 7：对象终结规则（Finalizer Rule）

对象的构造函数 happens-before 该对象的 finalize() 方法。

class Resource {
    FileInputStream stream;
    Resource() { stream = new FileInputStream("data.bin"); }  // 构造
    protected void finalize() {
        // 一定能看到构造函数中初始化的 stream
        // 构造 happens-before finalize
        stream.close();
    }
}
// 注意：finalize 已进入"死亡名单"——
// JDK 9 标记弃用，JDK 18（JEP 421）标记待移除
// 生产环境用 Cleaner 或 try-with-resources，别再用 finalize

这条规则现在更多是"考古"价值：finalize 的执行时机不确定、性能差、还容易出 bug，JVM 官方已明确要移除。记住结论就行：资源清理走 try-with-resources 或 Cleaner，finalize 面试题答完即弃。

规则 8：传递性（Transitivity）

如果 A happens-before B，B happens-before C，那么 A happens-before C。这是八条规则里最"值钱"的一条，因为它让简单的规则组合出强大的效果。

// volatile 的经典用法就是利用传递性：
int a = 1;            // A
int b = 2;            // B
volatile boolean flag = true;  // C（volatile write）

// A → B → C（程序顺序）→（volatile 写读）→ 后续操作
// 传递性保证：读到 flag=true 的线程，一定能看到 a=1, b=2

happens-before 是规范层面的"承诺"，而内存屏障（Memory Barrier / Memory Fence）是兑现承诺的硬件指令。JVM 在合适的位置插入屏障，CPU 看到屏障就"不敢乱动"。屏障一共四类，按"读写 × 读写"排列：

记忆技巧：名字里第一个操作在屏障前，第二个操作在屏障后。比如 StoreLoad = 屏障前的 Store 必须完成，屏障后的 Load 才能开始。

x86 上的实现：为什么强模型也要屏障

x86 是强内存模型（TSO），普通读写之间基本不乱序，唯独允许 Store → Load 重排（因为写缓冲区）。所以：

• 普通场景（LoadLoad / StoreStore / LoadStore）在 x86 上大多数是空操作，硬件天然满足；
• StoreLoad 是唯一必须显式执行的，x86 上由 mfence 指令或 lock 前缀指令（如 lock addl $0, 0(%rsp)）实现——它们会把当前处理器的写缓冲区（Store Buffer）全部排空并刷到缓存。

顺带说一句：JMM 的屏障要求是"保守放哨"的——它声明了最严格的插入位置，JIT 在具体平台上发现某类屏障是空操作（比如 x86 上的 LoadLoad）就省略掉。这也是"同一套 Java 代码，x86 上很快、ARM 上明显慢"的原因之一。

volatile 的底层实现就是内存屏障。JMM 规定（保守做法）：

• volatile 写之前插入 StoreStore 屏障（前面的普通写先落地），之后插入 StoreLoad 屏障（我的写立刻对外可见）；
• volatile 读之后插入 LoadLoad + LoadStore 屏障（后续普通读写不能越过我）。

把屏障落点和规则对上号：StoreStore 保证"写之前的写"先完成（配合规则 1），StoreLoad 保证写立刻对外可见（规则 3），读侧的 LoadLoad/LoadStore 保证读之后的普通操作不越过读（有序性）。

volatile 的完整语义

生产里怎么用 / 别怎么用

class Singleton {
    private static volatile Singleton instance;  // 必须 volatile！

    public static Singleton getInstance() {
        if (instance == null) {                  // 第一次检查（无锁）
            synchronized (Singleton.class) {
                if (instance == null) {              // 第二次检查（有锁）
                    instance = new Singleton();     // 问题在这里！
                }
            }
        }
        return instance;
    }
}

new Singleton() 在字节码层面是三步：

1. 分配内存空间
2. 调用构造函数初始化对象
3. 把引用指向分配的内存

第一次检查（无锁）是性能优化：单例已经建好就直接返回，避免每次抢锁。但它也让重排序的后果暴露给了无锁路径的读者——所以必须用 volatile 的 StoreStore 屏障钉死 ②③ 的顺序。

最后，生产里更推荐用静态内部类（Holder），它用类加载机制天然实现"延迟 + 线程安全"，连 volatile 都不用写：

class Singleton {
    private Singleton() {}

    private static class Holder {
        private static final Singleton INSTANCE = new Singleton();
    }
    // 类加载是线程安全的，Holder 只在首次 getInstance 时被加载
    public static Singleton getInstance() {
        return Holder.INSTANCE;
    }
}

volatile 和锁都是"要主动用"的机制，而 final 是被动生效的：final 字段在构造函数中正确赋值后，任何线程看到这个对象引用时，都一定能看到 final 字段的最终值——不需要任何同步。这就是 JSR-133 给 final 的承诺。

class ImmutablePoint {
    private final int x;   // final 字段
    private final int y;

    ImmutablePoint(int x, int y) { this.x = x; this.y = y; }
}

// Thread-1
ImmutablePoint p = new ImmutablePoint(3, 5);
cache = p;   // 发布到一个共享引用（如 volatile 字段或安全容器）

// Thread-2 拿到 cache 后：p.x 一定是 3，p.y 一定是 5，绝不可能是默认值 0

为什么能做到？JSR-133 规定：final 字段的写入之后要插入 StoreStore 屏障（防止 final 写被重排到构造函数之外），读者拿到引用后还有 LoadLoad 保证。实现上 JIT 会把这些屏障安排得比 volatile 更"便宜"。

三个必须说清的边界

• 安全发布是前提：如果构造函数里就把 this 泄露出去（比如在构造中 new Thread(...).start() 且线程里读了字段，或把 this 放进静态集合），final 的保证就失效——这叫 this 逸出（this Escape），是写框架代码时的高危点；
• final 只保护引用本身：如果 final 字段指向一个可变对象，只保证"这个引用不变"，不保证被引用对象内部字段的可见性——对象内部的状态更新仍需同步；
• final 不解决发布问题：final 字段的可见性针对"已经拿到引用"的线程，引用本身怎么传过去（volatile、锁、并发容器、start/join），还得靠其它规则。

把八条规则背下来只是第一步，真正的价值在于：遇到并发 Bug，不靠猜、不靠"跑 100 次没出问题"，而是用 happens-before 逐条推理。方法论就四步：

实战 1：优雅停机的"开关不生效"（第 1 站事故）

class GracefulShutdown {
    private volatile boolean running = true;  // 关键：volatile

    void stop()  { running = false; }        // 写（volatile write）

    void work() {
        while (running) {                       // 读（volatile read）
            // 业务处理...
        }
    }
}
// 推理：stop() 的写 happens-before work() 中下一次读（规则 3）
// 结论：running 加 volatile 即可，不需要 synchronized

实战 2：主线程 join 子线程后读结果

场景：主线程起了 10 个子线程各算一块数据，join() 全部结束后汇总。推理：每个子线程的所有写 happens-before 主线程从它的 join() 返回（规则 5），所以汇总代码不需要额外加锁。很多人习惯性地加一堆 synchronized，其实是多余的——用规则推一遍就能省下来。

实战 3：线程池 submit 后 get() 为什么安全

场景：Future<Result> f = pool.submit(callable); Result r = f.get();。推理：任务内的写 happens-before get() 返回（JUC 内部：任务结束写入 AQS 的 volatile state，get() 读 state 解锁，本质是规则 3 + 规则 8 的组合）。所以 Future 的结果读取是天然安全的——这也是为什么线程池场景极少需要自己再传 volatile 标志。

反模式：用 sleep "等可见"

自查清单

这是面试中最容易混淆的概念。很多人把 JMM 和 JVM 内存模型混为一谈，其实它们解决的是完全不同的问题：

// 面试官问："请解释一下 Java 的内存模型"
// 先确认他问的是哪个：

// 如果问的是 JMM（JSR-133）：
// → 聊 happens-before、volatile、可见性、内存屏障

// 如果问的是 JVM 运行时数据区：
// → 聊堆（新生代/老年代）、栈、方法区/元空间

// 如果不确定，可以主动区分：
// "Java 内存模型有两个层面，一个是 JSR-133 定义的
//  线程间可见性模型，另一个是 JVM 的运行时数据区划分，
//  您想了解哪方面？"