Java内存模型与happens-before规则最新详解：从JSR-133到并发编程

数码系统

相机 win10

测评 win11

手机智车

华为 Tesla

小米理想

苹果蔚来

游戏软件

LOL 抖音

原神微信

当前位置：首页

编程语言

Java内存模型与happens-before规则最新详解：从JSR-133到并发编程

热心网友时间：2026-07-21

转载

Java内存模型通过happens-before规则定义偏序关系，保证正确同步程序的可见性。volatile借助内存屏障（x86上为lock指令）实现写可见性，但无法保证原子性。final字段在构造器结束后具有freeze语义，前提是this不逸出。实际编程需注意DCL问题及64位变量非原子写。

先看一段示例代码，猜猜输出结果：

// src/main/ja va/com/example/JMMDemo.ja va
// 对应 OpenJDK 源码路径: hotspot/src/share/vm/runtime/thread.cpp
public class JMMDemo {
    static boolean flag = false;
    static int data = 0;
    public static void main(String[] args) throws Exception {
        Thread writer = new Thread(() -> {
            data = 42;         // 操作 1
            flag = true;       // 操作 2
        });
        Thread reader = new Thread(() -> {
            if (flag) {        // 操作 3
                System.out.println(data);  // 操作 4
            }
        });
        writer.start();
        reader.start();
    }
}

你认为 reader 线程一定会输出 42 吗？

答案：不一定。 在某些 JVM 实现上，你很可能看不到 42。原因并非“线程调度问题”，而是 JMM 允许指令重排序——操作 2 可能在操作 1 之前被执行（从 reader 的视角观察）。

这就引出了 JMM 要解决的核心矛盾：编译器/CPU 希望优化代码（重排序），而程序员期望可预测的结果（顺序一致性）。

JMM 的根本目标

JSR-133（Java 5 引入的 JMM 规范）明确了三项任务：

定义一组规则，告知程序员在何种情况下重排序是“不可见的”
提供一组原语（volatile、synchronized、final），让程序员表达同步意图
不禁止重排序，但规定重排序不能破坏“正确同步的程序”

JMM 最巧妙之处就在这里——它并不试图全面禁止重排序（那将扼杀所有优化），而是划出一条界限：在线程内部可以任意重排，但绝不能让另一个线程观察到中间状态。

重排序的来源

在讲解 JMM 之前，先明确重排序来自三个层面：

来源	层级	典型行为
编译器重排序	编译期	不改变单线程语义的前提下，调换指令顺序
处理器乱序执行	运行时	CPU 动态调度指令，只要结果等价
内存系统重排序	硬件层面	Store Buffer 导致写操作对其他核不可见

90% 的人只了解编译器重排序，却不知道 Store Buffer 带来的问题更为隐蔽。后面讲解 volatile 时会详细展开。

happens-before 规则：JMM 的基石

happens-before 并非一种“算法”或“实现”，它是一个偏序关系——定义在 Java 规范 17.4.5 节。其含义非常直接：

如果 A happens-before B，那么 A 的操作结果对 B 可见，且 A 的执行顺序在 B 之前（从 B 的视角看）。

注意措辞——“从 B 的视角看”意味着这只是一个约定，而非绝对的物理时间顺序。

八大规则

直接列出：

程序顺序规则：同一个线程中，前面的操作 happens-before 后面的（但这里说的是“语义上的前面”，实际可能重排）
volatile 规则：对一个 volatile 变量的写，happens-before 对该变量的读
锁规则：解锁 happens-before 后续的加锁（同一个锁）
传递性：如果 A happens-before B，B happens-before C，则 A happens-before C
start() 规则：线程的 start() 调用 happens-before 该线程的任何动作
join() 规则：线程的所有操作 happens-before 其他线程对该线程的 join() 返回
中断规则：interrupt() 调用 happens-before 检测中断事件
finalizer 规则：构造器完成 happens-before finalizer 的开始

重点在于 2、3、4 三条规则。其他几条在正常编程中不太容易踩坑。

规则如何“链”到一起

通过两个最常见的场景来说明。

场景一：volatile 的传递性

// 对应代码路径: openjdk/jdk/src/ja va.base/share/classes/ja va/lang/Thread.ja va
static volatile Thread currentThread;
// 线程 A
sharedVar = 1;           // 写普通变量
currentThread = Thread.currentThread();  // volatile 写
// 线程 B
Thread t = currentThread;  // volatile 读
int x = sharedVar;         // 读普通变量

根据规则 1，sharedVar = 1 happens-before currentThread = ...（同一线程内）。

根据规则 2，volatile 写 happens-before volatile 读。

根据规则 4（传递性），sharedVar = 1 就 happens-before int x = sharedVar。

所以 B 一定能看到 A 写入的 1。这就是 volatile 的“内存屏障”效果，本质上并非 volatile 本身有什么魔法，而是规则链保证了可见性。

场景二：锁的同步语义

// 对应代码路径: openjdk/hotspot/src/share/vm/runtime/objectMonitor.cpp
synchronized (lock) {
    sharedVar = 42;     // 临界区内
}
// 锁释放

另一个线程获取同一个锁后，一定能看到 sharedVar == 42。锁规则保证：释放锁之前的所有操作，对获取锁之后的代码可见。

volatile 的实现：内存屏障

早期认为 volatile 只是一个“禁止缓存”的标志位——后来查阅 OpenJDK 的实现才发现认知过于简单。

volatile 在字节码层面没有任何特殊指令，它只是添加了一个 ACC_VOLATILE 标志位。真正的魔法发生在 JVM 生成汇编时：

// x86 平台：volatile 写对应的汇编（通过 hsdis 反编译得到）
// 这段来自 OpenJDK hotspot/src/os_cpu/linux_x86/vm/orderAccess_linux_x86.hpp
0x000000011456b9c0: lock addl $0x0,(%rsp)

lock 前缀是关键。 它完成了三件事：

将当前 CPU 的 Store Buffer 全部刷新到内存（保证写可见）
让其他 CPU 核的缓存行失效（MESI 协议的 Invalid 状态）
相当于一个全功能的内存屏障——同时防止了编译器和 CPU 两端的重排序

以前一直以为 volatile 只是“不把变量缓存到寄存器”，看了汇编才发现 x86 上 volatile 的成本就是一条 lock 指令的延迟——大约 10-50 个 cycle。虽然不便宜，但相比一次 cache miss（上百 cycle）也算不上离谱。

volatile 的局限

volatile 不能保证原子性。经典的反例：

// 对应代码路径: openjdk/jdk/src/ja va.base/share/classes/ja va/lang/Thread.ja va
volatile int count = 0;
// 多个线程同时执行：
count++;  // 相当于 temp = count; temp + 1; count = temp; ——三步操作

三步操作在中间被打断，count 就会丢失更新。这个坑很多人踩过，线上有个计数器统计 QPS，使用 volatile int 加了一堆线程，结果统计值比实际少了约 30%。排查了很久才发现不是 volatile 的问题，而是没有理解 volatile 不做原子性保证。

final 的 JMM 语义：被低估的“安全初始化”

很多人知道 final 字段不可变，但不知道 JMM 为 final 做了特殊保证。

// 对应 OpenJDK 路径: hotspot/src/share/vm/oops/instanceKlass.cpp
public class SafeObject {
    final int x;
    int y;
    SafeObject() {
        x = 1;  // final 写
        y = 2;  // 普通写
    }
}

JMM 保证：只要构造器没有将 this 逸出，其他线程看到 SafeObject 对象时，x 一定已经被正确初始化（= 1），而 y 可能还是默认值 0。

这个保证来自 JSR-133 新增的“final 字段的 freeze 语义”——在构造器结束后，JVM 会插入一个 StoreStore 屏障，确保 final 字段的写不会被重排序到构造器之外。

这个特性被很多人忽略了。在阅读 Dubbo 的扩展加载源码时，发现它大量使用 final 字段来保证安全发布，而不是用 volatile 或锁。这是一种更轻量的并发安全手段。

final 的“坑”

public class UnsafeFinal {
    final int x;
    static UnsafeFinal instance;
    UnsafeFinal() {
        x = 1;
        instance = this;  // this 逸出！—— final 保证失效
    }
}

如果构造器中把 this 暴露出去，另一个线程通过 instance 访问 x —— 不保证能看到 1。final 的 freeze 语义要求构造器没结束前不让其他线程看到对象。

实际编程中的 JMM 陷阱

陷阱 1：过度依赖“直觉”

// 一个“看似正确”的懒加载
// 对应路径: openjdk/jdk/src/ja va.base/share/classes/ja va/lang/ClassValue.ja va
class LazyInit {
    private static ExpensiveObject instance;
    public static ExpensiveObject getInstance() {
        if (instance == null) {             // 第一次检查
            synchronized (LazyInit.class) {
                if (instance == null) {     // 第二次检查
                    instance = new ExpensiveObject();  // 可能出问题！
                }
            }
        }
        return instance;
    }
}

new ExpensiveObject() 在 JVM 层面是三步：分配内存 → 调用构造器 → 将引用赋值给 instance。步骤 2 和 3 可能被重排序！ 另一个线程在第一次检查时看到 instance != null，但构造器还没执行完——从而拿到一个半初始化对象。

这就是经典的 DCL 问题。解决方案是加 volatile（JDK 5+ 才生效）或者使用内部静态类。

陷阱 2：64 位变量的非原子写

JVM 规范允许 long/double 的 64 位写分成两个 32 位写。这不是理论推测——在 32 位 ARM 的嵌入式 Java 环境下可以复现：

// 对应路径: openjdk/jdk/src/ja va.base/share/classes/ja va/lang/Double.ja va
long shared = 0x00000000FFFFFFFFL;
// 线程 A 写：
shared = 0xAAAAAAAA00000000L;
// 线程 B 读：
// 可能读到 0x0000000000000000L（原值）
// 或 0xAAAAAAAAFFFFFFFFL（高字被改，低字没改）——word tearing！

解决方案就是加 volatile——volatile 保证 long/double 的写是原子的。