JMM通过happens-before规则约束重排而非禁止重排，它在关键位置插入内存屏障（如volatile写后加StoreStore+StoreLoad），确保跨线程操作的可见性与有序性；程序顺序、锁、volatile、final等均提供happens-before语义，覆盖DCL等危险重排场景。
Java 内存模型（JMM）本身不禁止指令重排，而是通过 happens-before 规则为重排划出“安全边界”——只要两个操作之间存在 happens-before 关系，JVM 就必须保证：前一个操作的结果对后一个操作可见，且不会被重排打乱逻辑顺序。它不是靠“禁止所有重排”来实现线程安全，而是用可预测的约束替代不可控的自由重排。
happens-before 是怎么挡住重排的
它不直接干预编译器或 CPU 的重排行为，而是在关键位置插入内存屏障（memory barrier），告诉底层：“这里前后某些类型的读写不能越过彼此”。例如：
- volatile 写之后插入 StoreStore + StoreLoad 屏障 → 禁止写 volatile 前后的普通写被重排到它后面，也禁止后续读被提前到它前面；
- synchronized 解锁前插入 StoreStore + StoreLoad，解锁后插入 LoadLoad + LoadStore → 保证临界区内写入全部刷出，且加锁时清空本地缓存；
- 程序顺序规则虽不生成硬件屏障，但它是所有其他规则的基础：单线程内 A 在 B 前，就天然要求 A 的结果可用于 B 的计算，编译器不会破坏这种数据依赖性重排。
哪些重排真正危险？happens-before 怎么覆盖它们
真正引发 bug 的重排，是那些跨线程、无数据依赖、又没同步约束的操作。比如：
- DCL（双重检查锁定）中，对象构造未完成就被发布（new 指令重排为：分配内存 → 设置引用 → 初始化）；
- flag = true 和 data = 42 本该成对出现，却被重排成先写 flag、再写 data，导致另一个线程看到 flag == true 却读到 data = 0；
这些场景中，happens-before 规则通过 volatile（写 flag happens-before 读 flag）、锁（解锁 happens-before 后续加锁）、或 final 字段初始化（构造结束 happens-before 引用赋值）等机制，把原本松散的操作链拧成一条有向路径，让重排无法切断这条路径上的可见性传递。
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
立即学习“Java免费学习笔记（深入）”；
不用 synchronized 也能靠 happens-before 控制重排
很多人误以为只有加锁才能防重排，其实 volatile、Thread.start()、Thread.join()、final 字段写入等都自带 happens-before 语义：
- 启动新线程时，start() 调用 happens-before 线程内第一条语句 → 主线程初始化的数据对子线程可见；
- 子线程写 volatile flag = true，主线程 while(flag==0) 读到 true 后，就能看到 flag 之前所有已发生的操作（如对象字段赋值）；
- final 字段在构造器中赋值，构造完成那一刻，就建立了对该字段的 happens-before 关系，确保其他线程看到对象引用时，final 字段已是初始化完成状态。
写代码时怎么用好这个规则
不必记住八条规则的全部细节，关键是抓住三个动作模式：
- 发布共享状态时，用 volatile 或锁保护标志位（如用 volatile boolean ready 控制资源是否就绪）；
- 共享对象初始化完成后，再让它逃逸出当前线程（避免未完成构造的对象被其他线程拿到）；
- 读取共享状态前，确认已有明确的 happens-before 链到达该读操作（比如先看到 volatile 变量为 true，再读普通变量）。
没有 happens-before 关系的操作，JMM 对它们的执行顺序和可见性不做任何承诺——这不是缺陷，而是设计：它把控制权交还给开发者，用最小代价换取最大性能。
