happens-before 是一组显式定义的偏序规则，用于判断操作可见性与重排序约束；它不是时间先后关系，也不保证代码顺序即执行顺序。
happens-before 是什么，不是什么
happens-before 不是时间先后关系，也不是 JVM 保证“代码写在前面就一定先执行”。它是一组**显式定义的偏序规则**，用于判断一个操作是否对另一个操作可见、是否可被重排序。只有当 A happens-before B 成立时，JVM 才保证：A 的写入对 B 可见，且编译器/JIT/处理器不会把 B 的读重排到 A 的写之前。
六条核心 happens-before 规则怎么用
实际编码中，你几乎只靠其中四条落地：
-
程序顺序规则：同一个线程里，按代码顺序，前一条语句happens-before后一条（但仅限于存在数据依赖或同步约束时；纯计算语句可能被重排序） -
监视器锁规则：对同一个Object，unlock()操作happens-before后续任意线程对该对象的lock()操作 -
volatile 变量规则：对同一volatile字段，写操作happens-before后续任意线程对该字段的读操作 -
线程启动规则：Thread.start()调用happens-before新线程的run()方法中任意操作
注意：Thread.join() 和 final 字段规则 虽然也属标准，但日常编码中较少主动依赖——前者常被 CountDownLatch 或 CompletableFuture 替代，后者只在构造函数内完成 final 字段赋值才生效。
常见误用：volatile 不能替代 synchronized 的场景
很多人以为只要加了 volatile 就能避免竞态，这是错的。它只保可见性和禁止重排序，不保原子性。
立即学习“Java免费学习笔记（深入）”；
public class Counter {
private volatile int count = 0;
public void increment() {
count++; // 非原子：读-改-写三步，volatile 不阻止其他线程在此期间插入读或写
}
}
上面代码仍会丢失更新。必须用：
-
synchronized块包裹整个increment() - 或改用
AtomicInteger（其incrementAndGet()内部用 CAS +volatile+ 内存屏障实现原子性）
换句话说：volatile 只解决“我改了，别人马上看到”，不解决“我改的时候别让人插手”。
happens-before 在线程池和 CompletableFuture 中怎么体现
现代 Java 并发库底层仍靠上述规则，但封装后容易忽略内存语义：
-
ExecutorService.submit(Runnable)：提交动作happens-before线程池中该任务的执行开始（基于线程启动 + 锁规则组合） -
CompletableFuture.thenApply(fn)：当前 stage 完成（包括其结果写入）happens-beforefn执行；但fn默认在 ForkJoinPool 线程中运行，若需与主线程同步，得显式用thenApplyAsync(fn, executor)或join()触发 join 规则
比如漏掉 join() 直接访问返回值，可能读到默认初始化值（如 0 或 null），因为没有建立 happens-before 链。
真正难的不是记住六条规则，而是写出一段没显式同步却能正确传递状态的代码时，你能画出那条 happens-before 链——中间断一环，就可能偶发 bug。
