happens-before 是可见性与有序性的逻辑契约而非时间约束；它保证若A happens-before B，则A的结果对B可见且禁止破坏该关系的重排序。
happens-before 不是执行顺序的硬性时间约束，而是可见性与有序性的逻辑契约——它不保证 A 一定在 B 前面运行，只保证如果 A happens-before B，那么 A 的结果对 B 可见，且编译器/JVM 不会做破坏该关系的重排序。
为什么写完 flag = true，另一个线程却读不到？
这是最典型的可见性失效现象：没有建立 happens-before 关系，JVM 和 CPU 都可能把写操作缓存在工作内存或寄存器里，不刷回主内存；读线程也永远看不到更新。
- 普通变量（如
boolean flag = false）不带同步语义，flag = true和后续if (flag)之间无 happens-before，读线程可能永远循环 - 即使加了
System.out.println或Thread.sleep，也不能建立 happens-before，只是“碰巧”让缓存刷新了而已 - 真正起作用的是规则本身：用
synchronized、volatile、Thread.start()等显式触发规则
volatile 怎么靠一条规则就解决“读不到”问题？
volatile 变量规则明确指出：对 volatile 变量的写操作 happens-before 后续任意线程对该变量的读操作。这带来两个底层保障：
- 写操作后插入
StoreStore+StoreLoad内存屏障，强制刷新工作内存到主内存 - 读操作前插入
LoadLoad+LoadStore屏障，强制从主内存重新加载值 - 同时禁止编译器将该变量的读写与其他指令重排序（如禁止把
data = 42重排到flag = true之后）
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 操作。这意味着：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
立即学习“Java免费学习笔记（深入）”；
- 线程 A 在
synchronized块末尾释放锁时，会把所有临界区内修改的共享变量（如count++）强制刷回主内存 - 线程 B 进入下一个
synchronized块前，必须从主内存重新加载这些变量（而不是用自己工作内存里的旧副本） - 这个过程不依赖
volatile，也不需要额外声明，只要锁对象相同，规则自动生效
注意：如果两个线程用的不是同一把锁（比如不同实例、不同字段），规则不成立 —— 这是并发 bug 最隐蔽的来源之一。
容易被忽略的“传递性”和“启动/终止”场景
很多人只记住了前三条，却在跨线程初始化或等待时栽跟头：
-
线程启动规则：主线程调用
thread.start()之前的所有操作，happens-before 子线程的任意操作。所以可以在start()前设置好配置对象，子线程直接安全使用 -
线程终止规则：子线程内所有操作 happens-before 主线程调用
thread.join()返回。因此join()后能安全读取子线程写入的结果变量 - 传递性规则：A → B 且 B → C，则 A → C。这是组合多个同步原语（如先写 volatile、再进 synchronized）仍能保持可见性的基础
真正难的从来不是记住八条规则，而是当代码里混用 volatile、synchronized、Lock、AtomicInteger 时，能否画出完整的 happens-before 图——漏掉任意一条边，就可能埋下竞态隐患。
