happens-before 是可见性契约而非执行顺序，它保证A对共享变量的修改对B可见且禁止字长撕裂；常见于程序顺序、volatile读写、锁、start()和join()五种场景，但volatile不保证原子性。

happens-before 不是执行顺序，而是可见性契约

它不保证「A 一定在 B 前面 CPU 执行」，只承诺：如果 A happens-before B，那么 A 对共享变量的修改，对 B 一定是可见的；且 B 不会看到 A 写了一半的 long 或 double（即禁止字长撕裂）。

常见错误现象：volatile 字段没加，线程 B 死循环读 flag == false 永远不退出；或者看到 flag == true 却读到 data 是 0（未初始化值）。

• 根本原因不是“代码写得慢”，而是 JVM 和 CPU 允许重排序 + 缓存不一致
• 只要没建立 happens-before 关系，编译器、JIT、CPU 都可能把 data = 42 重排到 flag = true 后面
• 加 volatile 是最轻量的解法——它在写后插入写屏障，在读后插入读屏障，强制刷缓存+禁重排

哪些操作天然构成 happens-before？记住这 5 条硬规则

不用背全 8 条，日常开发真正高频用到的是以下 5 种场景，其他基本靠 synchronized 或 java.util.concurrent 底层封装兜底：

• 程序顺序规则：同一线程内，x = 1 happens-before y = x + 1（控制流路径中前序操作 → 后续操作）
• volatile 规则：对 volatile 变量 v 的写 happens-before 后续任意线程对该 v 的读（注意：“后续”指时钟上发生时间晚，不一定是代码写在后面）
• 锁规则：unlock() happens-before 后面对同一把锁的 lock()（哪怕发生在不同线程）
• start() 规则：主线程调用 t.start() happens-before 线程 t 的 run() 第一行
• join() 规则：线程 t.join() 返回 happens-before 当前线程继续执行下一行（即你能安全读 t 写过的变量）

容易踩的坑：synchronized 块里改了非 final 字段，但没在 unlock 后立刻被其他线程读——这时仍需靠锁的配对使用来建立关系，单次加锁不能跨方法保可见性。

立即学习“Java免费学习笔记（深入）”；

Java Development Manual

Java开发手册规约集合，基于阿里巴巴Java开发手册（嵩山版）。 涵盖7大维度：编程规约、异常日志、单元测试、安全规约、MySQL数据库、工程结构、设计规约。 当用户需要：(1) 编写或审查Java代码 (2) 检查命名/代码规范 (3) 处理异常和日志 (4) 编写单元测试 (5) 安全编码 (6) 数据库设...

下载

为什么 volatile 能解决可见性，却不能替代 synchronized？

volatile 保证可见性和禁止重排序，但不保证原子性。这是它和 synchronized 最本质的区别。

• 能用 volatile：状态标志（running = false）、一次性发布（instance != null 的 DCL 单例）
• 不能用 volatile：counter++（读-改-写三步非原子）、多个字段协同更新（如 size 和 elements[] 必须一起变）
• 性能影响：X86_64 上 volatile 写仅多一条 lock xchg 指令，开销极小；但频繁写可能触发缓存行失效，间接拖慢邻近变量访问

示例对比：

volatile boolean shutdownRequested = false;
// ✅ 安全：一个线程设为 true，另一个线程一定能及时看到
while (!shutdownRequested) { /* ... */ }
<p>volatile int counter = 0;
// ❌ 危险：两个线程同时执行 counter++，结果可能只 +1
counter++;

传递性是隐式桥梁，也是最容易漏掉的逻辑链

happens-before 支持传递：若 A hb B 且 B hb C，则 A hb C。这个特性让看似松散的操作能串成完整可见性链。

• 典型场景：DCL 单例中，构造函数末尾对 instance 的 volatile 写 → 后续线程读 instance → 该读又 happens-before 后续对 instance 字段的访问
• 陷阱在于“中间环节断链”：比如你忘了把 instance 声明为 volatile，那即使构造完成，其他线程也可能看到部分初始化的对象
• 调试时看不到问题？因为 JIT 优化和 CPU 缓存行为有随机性，问题往往只在高并发、多核、特定负载下暴露

真正难的从来不是记住规则，而是写完代码后，能快速画出线程间所有可能的 happens-before 路径——尤其当涉及多个 volatile 变量、锁嵌套、回调或 Future 时，少画一步就可能埋下偶发 bug。