在Java中happens before规则如何理解_Java内存模型解析_技术教程

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 操作。这意味着：

线程 A 在 synchronized 块末尾释放锁时，会强制把块内所有共享变量修改（如 count++）刷回主内存
线程 B 进入同一把锁的 synchronized 块前，必须从主内存重新加载这些变量（而不是用自己工作内存里的旧副本）
这个过程不要求变量本身是 volatile，也不需要额外声明，只要锁对象相同，规则自动生效

真正容易被忽略的点是：happens-before 是“链式传递”的。比如主线程调用 thread.start() → 子线程执行 → 子线程写 volatile flag → 主线程读 flag，这一整条链只要每段都满足规则（启动规则 + volatile 规则），最终就能保证主线程看到子线程写入的全部结果。断掉任何一环，可见性就没了。