happens-before 是可见性契约而非时间先后，核心是“谁的结果必须被谁看见”；程序顺序、监视器锁、volatile变量、线程启动/终止四条规则最常用，缺一导致读不到最新值或出现半构造对象。
happens-before 不是时间先后，而是可见性契约
你写 x = 1 在前、flag = true 在后，不代表其他线程一定能先看到 x 的值——除非它们之间存在 happens-before 关系。JMM 不保证物理执行顺序，只保证：如果 A happens-before B，那么 A 对共享变量的修改，对 B 一定可见；且 JVM 和 CPU 不会做破坏这个语义的重排序。
- 它不是“谁先跑完”，而是“谁的结果必须被谁看见”
- 没有 happens-before，读操作可能看到未初始化的值、旧值，甚至“半构造对象”
- 编译器可以重排
int a = 1; int b = 2;，但绝不能把b = a + 1提到a = 1前面——因为程序顺序规则强制了这个 happens-before
最常用的四条规则，直接决定你代码是否线程安全
不用背全八条，日常开发里真正高频起作用的是这四条，每一条都对应一个典型同步手段：
-
程序顺序规则：同一线程内，
a = 1happens-beforeb = a + 1—— 单线程永远可靠，但跨线程不传递 -
监视器锁规则：线程 A 退出
synchronized(lock)，和线程 B 进入同一synchronized(lock)构成 happens-before —— 锁不仅是互斥，更是内存屏障 -
volatile 变量规则：
ready = true（写 volatile） happens-before 后续任意线程的if (ready)（读 volatile）—— 这是发布-订阅模式的底层依据 -
线程启动/终止规则：主线程调用
thread.start()之前的所有操作，happens-before 子线程的任意操作；子线程所有操作 happens-before 主线程thread.join()返回 —— 所以你能放心在join()后读子线程写过的普通变量
为什么加了 volatile 还读不到最新值？常见断链点
volatile 只保障“对它的写 happens-before 对它的读”，不自动延伸到其他变量。这是最多人栽跟头的地方：
- 错误写法：
data = 42; ready = true;（data是普通变量）→ready是 volatile，但data的写和后续读之间没有 happens-before - 正确写法：必须让读端也依赖
ready的读，比如if (ready) { System.out.println(data); }—— 此时 volatile 读建立了与前面所有写（含data = 42）的传递性链 - 更隐蔽的坑：两个 volatile 变量之间无自动关联，
v1 = true和v2 = false并不构成 happens-before，除非你用传递性手动串起来
用锁或 volatile 时，别漏掉“隐式屏障”的副作用
synchronized 和 volatile 不仅提供可见性，还禁止特定方向的重排序，这是它们能建立 happens-before 的底层机制：
立即学习“Java免费学习笔记（深入）”；
-
synchronized块入口插入 load-load / load-store 屏障，出口插入 store-store / load-store 屏障 -
volatile写插入 store-store + store-load 屏障，读插入 load-load + load-store 屏障 - 这意味着：即使你没显式读写某个变量，只要它在临界区里被修改，也会被强制刷出；只要你在 volatile 读之后访问某变量，就一定能见到该读操作之前所有已发生的写
真正难的不是记住规则，而是识别哪两个操作之间缺了那条 happens-before 链——尤其当逻辑分散在多个方法、多个类里时，链一断，bug 就藏得极深。
