17370845950

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 就能避免竞态，这是错的。它只保可见性和禁止重排序，不保原子性。

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-before fn 执行；但 fn 默认在 ForkJoinPool 线程中运行，若需与主线程同步，得显式用 thenApplyAsync(fn, executor) 或 join() 触发 join 规则

比如漏掉 join() 直接访问返回值，可能读到默认初始化值（如 0 或 null），因为没有建立 happens-before 链。

真正难的不是记住六条规则，而是写出一段没显式同步却能正确传递状态的代码时，你能

画出那条 happens-before 链——中间断一环，就可能偶发 bug。