当前位置：首页 > 文章列表 > 文章 > java教程 > 重排约束是指在多线程环境下，为了保证程序的正确性，对指令执行顺序施加的限制。这些限制防止编译器或CPU对指令进行不必要的重排，从而避免出现数据竞争、可见性问题等并发错误。Java内存模型（JMM）通过以下方式限制编译与CPU的重排：内存屏障（MemoryBarrier）JMM在适当的位置插入内存屏障，确保某些操作在其他操作之前或之后执行。例如：volatile变量的读写会插入内存屏障，防止指令重排

重排约束是指在多线程环境下，为了保证程序的正确性，对指令执行顺序施加的限制。这些限制防止编译器或CPU对指令进行不必要的重排，从而避免出现数据竞争、可见性问题等并发错误。Java内存模型（JMM）通过以下方式限制编译与CPU的重排：内存屏障（MemoryBarrier）JMM在适当的位置插入内存屏障，确保某些操作在其他操作之前或之后执行。例如：volatile变量的读写会插入内存屏障，防止指令重排

2026-03-07 14:18:55 0浏览收藏

本文深入剖析了Java内存模型（JMM）如何通过内存屏障和happens-before契约，精准约束编译器与CPU的重排序行为——volatile并非“禁止所有重排”，而是以StoreStore/StoreLoad等屏障为锚点，在关键读写间建立可见性边界；它解决了双重检查锁中对象部分初始化这一经典陷阱，却无法保证复合操作原子性；happens-before本质是可见性承诺而非执行时序保证；而真正理解重排的关键在于认清：它不是缺陷，而是性能基石，JMM的智慧恰在于以最小干预（volatile/synchronized/final）划定可控例外，一旦脱离这些语义锚点，程序便坠入未定义行为的危险荒野。

什么是并发编程中的重排约束_JMM对编译器优化与CPU指令重排的底线

为什么 volatile 能禁止重排序，但普通变量不能

因为 JMM 对 volatile 变量施加了特殊的内存语义：写操作后插入 StoreStore + StoreLoad 屏障，读操作前插入 LoadLoad + LoadStore 屏障。这些屏障不是 Java 代码，而是 JVM 在生成字节码或 JIT 编译时，向底层指令流中注入的内存栅栏（Memory Barrier），强制限制编译器和 CPU 的重排自由度。

普通变量的读写，JMM 不做任何顺序约束——编译器可把 a = 1 和 flag = true 换序，CPU 也可能让 store flag 先于 store a 刷出到缓存
volatile 写操作会“冲刷”Store Buffer，确保之前所有写对其他核可见；volatile 读操作会“清空”Invalidate Queue，并强制从缓存一致性协议（如 MESI）中拉取最新值
注意：volatile 仅禁止与它自身存在 happens-before 关系的操作被重排，不保证复合操作（如 counter++）原子性

双重检查锁（DCL）里不加 volatile 会发生什么

典型错误是单例对象构造完成前，引用就被其他线程看到——即“部分初始化”问题。根源在于：对象创建包含三步：memory allocate → ctor call → assign reference。JIT 可能将第三步提前，而 volatile 强制这三步在语义上不可重排，且对其他线程可见。

现象：线程 B 调用 getInstance() 得到非 null 的 instance，但访问其字段时报 NullPointerException 或返回默认值
根本原因不是“没同步”，而是“同步了但重排绕过了同步边界”——synchronized 块内仍允许构造过程被重排
修复只需把 private static Singleton instance 改为 private static volatile Singleton instance，无需改逻辑

happens-before 不是执行顺序，而是可见性契约

很多人误以为 happens-before 表示“一定先执行”，其实它只规定：如果 A happens-before B，则 A 的结果对 B 是可见的。这个关系不传递执行时序，也不阻止重排，只是划定一个“安全可见边界”。

例如：synchronized 块解锁 happens-before 后续同锁的加锁，但两个 synchronized 块之间若无锁竞争，JVM 仍可重排它们内部指令
程序顺序规则（每个线程内，按代码顺序，前一条 happens-before 后一条）是唯一保障单线程语义的规则；其余规则（如 volatile 规则、传递性）都是为多线程可见性服务
写 final 字段的构造器结束 happens-before 构造器返回——这是 final 域安全发布的底层依据，但仅对 final 字段生效，对普通字段无效

编译器重排和 CPU 重排要分开应对

编译器（javac / JIT）重排发生在字节码生成或运行时编译阶段；CPU 重排发生在指令执行时。JMM 必须双管齐下：对前者靠禁止特定优化（如禁止跨 volatile 读写的指令移动），对后者靠插入内存屏障（如 x86 的 mfence、lfence）。

JIT 编译器看到 volatile 字段访问，会禁用相关优化，比如不把循环中对 volatile 的读提升到循环外
在 x86 上，volatile 写自动带 StoreStore + StoreLoad 语义（因 x86 内存模型较强），但 ARM/AArch64 必须显式插入 dmb ishst 和 dmb ish 才等效
别试图用 Thread.yield() 或空循环“防止重排”——它们既不构成 happens-before，也不触发内存屏障，纯属无效操作

真正难的是理解：重排不是 bug，是硬件和编译器默认开启的性能开关；JMM 不是消灭重排，而是用最小代价划出可控的例外区域。一旦离开 volatile、synchronized、final 这些明确锚点，你就回到了“未定义行为”的荒野。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。