Java内存模型通过happens-before原则定义操作偏序关系，确保线程间可见性；核心规则包括程序顺序、监视器锁、volatile变量、线程启动/终止及传递性，用于判断并发代码安全性。
Java 内存模型（JMM）用 happens-before 原则定义了操作之间的偏序关系，它不直接描述底层执行顺序，而是规定哪些操作的结果对其他线程可见。分析并发代码时，只要两个操作之间存在 happens-before 关系，前一个操作的写结果就一定对后一个操作可见；反之，若不存在该关系，就可能出现重排序或读到过期值。
从常见 happens-before 规则入手
不必死记全部规则，先掌握最常影响实际代码的几条：
- 程序顺序规则：同一个线程内，按代码顺序，前面的操作 happens-before 后面的操作（注意：不是执行顺序，而是语义顺序；编译器/JVM 可重排序，但不能破坏这个偏序）
- 监视器锁规则：对同一个锁，unlock 操作 happens-before 后续对该锁的 lock 操作（这是 synchronized 正确性的基础）
- volatile 变量规则：对一个 volatile 变量的写操作 happens-before 后续对该变量的读操作
- 线程启动规则：Thread.start() 调用 happens-before 该线程的任何动作
- 线程终止规则：线程中所有操作都 happens-before 其他线程检测到该线程已结束（如 join() 返回）
- 传递性：如果 A happens-before B，且 B happens-before C，则 A happens-before C（这是串联多个操作的关键）
用 happens-before 分析典型问题
比如判断以下代码是否线程安全：
volatile boolean flag = false;int x = 0;
Thread A:
x = 42; // A1
flag = true; // A2
Thread B:
if (flag) { // B1
System.out.println(x); // B2
}
A2 和 B1 是 volatile 读写，满足 volatile 规则 → A2 happens-before B1；A1 在 A2 前（程序顺序）→ A1 happens-before A2；再结合传递性 → A1 happens-before B1。而 B2 在 B1 后（程序顺序）→ B1 happens-before B2。最终 A1 happens-before B2，所以 B2 一定能看到 x == 42。
立即学习“Java免费学习笔记（深入）”；
若 flag 不是 volatile，A2 和 B1 之间无 happens-before，B1 可能读到旧值，也可能读到新值，但即使读到 true，A1 和 B2 之间也无保证，x 可能仍为 0。
警惕“看似有序”实则无保障的情况
常见误区是认为“先执行完 A 再启动 B”，就天然有可见性。例如：
x = 1; // A1Thread t = new Thread(() -> {
System.out.println(x); // B1
});
t.start(); // A2
A1 和 A2 是程序顺序 → A1 happens-before A2；A2 和 t 中任意操作满足线程启动规则 → A2 happens-before B1；传递得 A1 happens-before B1。这段是安全的。
但若写成：
x = 1; // A1t.start(); // A2
// 忘记 join 或其他同步手段
System.out.println("done");
主线程无法保证看到 t 的输出，t 也无法保证看到主线程在 start() 之后写的变量（除非另有同步）。这里只保证 t 能看到 start() 之前主线程的写，不保证之后的。
结合工具和习惯增强分析可靠性
人工推导容易遗漏传递链。建议：
- 画简化的 happens-before 图：节点是关键操作（读/写/lock/unlock），边表示规则产生的关系
- 对共享变量，明确每个读写由谁执行、是否加锁或 volatile
- 避免依赖“执行先后”直觉，专注找每一对读写之间是否存在可传递的 happens-before 链
- 优先使用高层同步工具（如 ConcurrentLinkedQueue、AtomicInteger），它们内部已封装正确 happens-before
不复杂但容易忽略：happens-before 是关于可见性和有序性的契约，不是性能优化提示，也不是 JVM 实现细节——它是你编写正确并发代码的逻辑标尺。
