happens-before 是“可见性+顺序性”的逻辑契约，而非时间先后；它通过规则链确保前操作对后操作的共享变量修改可见，链断裂则可能导致重排序、读旧值等并发问题。

happens-before 不是时间先后，而是“可见性+顺序性”的逻辑契约。只要两个操作之间能通过某条规则（或传递链）建立 happens-before 关系，前一个操作对共享变量的修改，就一定对后一个操作可见；反之，若无法推导出该关系，JVM 就可能重排序、缓存不刷新、读到旧值——哪怕代码看起来“理应”按顺序执行。

核心：抓住“谁对谁可见”这个出发点

别死记八条规则，先想清楚一个问题：线程 A 改了一个变量，线程 B 什么时候能稳定看到？答案就藏在 happens-before 链里。每一条规则，本质都是为“跨线程可见性”提供一条可信路径：

• 单线程内靠程序顺序规则——a=1; b=a+1; 中，a 赋值必然对 b 可见；
• 多线程间靠锁规则或volatile 规则搭桥——释放锁的动作，把临界区所有写入“推送”给下一个获取锁的线程；写 volatile 变量，则把之前所有写入“刷出”到主内存；
• 线程生命周期靠启动/终止规则——start() 前的操作，对子线程入口可见；join() 后的操作，能看到子线程全部结果；
• 所有规则都服从传递性——这是串联不同机制的关键，比如 volatile 写 → volatile 读 → synchronized 临界区，整条链就构成完整可见性保障。

实战中真正卡住人的，其实是“链断了”

很多并发 bug 的根源，不是没加锁、没用 volatile，而是 happens-before 链没闭合。典型例子：

javascript-typescript-typescript-scaffold

你是 TypeScript 项目架构专家，专注于脚手架搭建生产就绪的 Node.js 和前端应用。生成包含现代工具链（pnpm、Vite、Next.js）、类型

下载

• 双重检查单例中，new Singleton() 包含三步：分配内存、初始化对象、将引用赋值给 singleton。若没用 volatile 修饰 singleton 字段，第 2 步和第 3 步可能被重排序，导致其他线程拿到未初始化完成的对象；
• 用普通 boolean 标志位通知线程退出，while(!flag) {} 可能永远不退出——因为 flag 的写和读之间没有 happens-before，JVM 允许线程一直读缓存值；
• 只对写操作加锁、读操作不加锁——解锁与后续读之间无 happens-before，读线程看不到最新值。

判断有没有问题，三步走就够了

面对一段多线程代码，快速验证是否安全：

• 找出所有读写同一共享变量的位置；
• 对每一对“写→读”，尝试画出 happens-before 链：是同一线程？用了 synchronized？涉及 volatile？有 start/join？能否靠传递性串起来？
• 只要有一对写读之间找不到任何链，就存在可见性风险，必须补规则（加锁、加 volatile、用 AtomicXXX 等）。

它不神秘，但必须当真

happens-before 是 JMM 给程序员的明确承诺，不是理论模型。JVM、编译器、CPU 都必须遵守——只要链存在，结果就确定；链不存在，一切皆有可能。把它当成接口协议：你按规则写，它就保你可见；你漏了环节，它不背锅。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南