happens-before 是“结果可见性”契约而非时间顺序，如 volatile 写操作 happens-before 后续读操作，通过内存屏障和禁止重排确保 data=42 对 reader 可见。
happens-before 不是“谁先执行”，而是“谁的结果对谁可见”的契约。 它不保证时间顺序，只保证：如果 A happens-before B，那么 A 的写入结果一定对 B 可见，且 JVM/编译器不会做破坏该关系的重排序。没建立这个关系，哪怕代码写在前面，另一线程也可能永远读不到新值。
为什么 flag = true 后，另一个线程 if (flag) 还卡死？
这是最典型的可见性失效——普通变量（如 boolean flag = false）没有同步语义，flag = true 和后续 if (flag) 之间没有 happens-before 关系。JVM 可能把写操作缓存在工作内存或寄存器里，不刷回主内存；读线程也一直用自己缓存的旧值。
- 加
System.out.println或Thread.sleep不能解决问题，只是“碰巧”触发了缓存刷新，不可靠 - 真正起作用的是显式同步机制：比如把
flag声明为volatile，或用synchronized包裹读写逻辑 - 即使
data = 42写在flag = true前面，若flag非 volatile，读线程看到true时仍可能读到data == 0
volatile 怎么靠一条规则就解决“读不到”问题？
volatile 变量规则明确：对 volatile 变量的写操作 happens-before 后续任意线程对该变量的读操作。这带来两层保障：
- 写操作后插入
StoreStore + StoreLoad内存屏障，强制把工作内存中所有待写数据（包括前面的data = 42）刷回主内存 - 读操作前插入
LoadLoad + LoadStore屏障，强制从主内存重新加载该变量（及之前被屏障“拖住”的其他写） - 同时禁止编译器将
data = 42重排到flag = true之后——这是volatile的“指令重排抑制”能力，不是靠“刷新”实现的
private volatile boolean flag = false;
private int data = 0;
public void writer() {
data = 42; // 普通写，但被 volatile 写“锚定”
flag = true; // volatile 写 → 建立 happens-before 边界
}
public void reader() {
if (flag) { // volatile 读 → 能看到 data == 42
System.out.println(data);
}
}
synchronized 解锁和加锁之间到底发生了什么？
监视器锁规则说：一个线程对锁的 unlock 操作 happens-before 另一个线程对该锁的 lock 操作。这意味着：
立即学习“Java免费学习笔记（深入）”；
- 线程 A 在
synchronized块末尾释放锁时，会强制把块内所有共享变量修改（如count++）刷回主内存 - 线程 B 进入同一把锁的
synchronized块前，必须从主内存重新加载这些变量（而不是用自己工作内存里的旧副本） - 这个过程不要求变量本身是
volatile，也不需要额外声明，只要锁对象相同，规则自动生效
真正容易被忽略的点是：happens-before 是“链式传递”的。比如主线程调用 thread.start() → 子线程执行 → 子线程写 volatile flag → 主线程读 flag，这一整条链只要每段都满足规则（启动规则 + volatile 规则），最终就能保证主线程看到子线程写入的全部结果。断掉任何一环，可见性就没了。
