Java 中 synchronized 保证有序性的底层机制分析

synchronized通过内存屏障和Monitor语义保证有序性：monitorenter前插入LoadLoad+LoadStore屏障，monitorexit后插入StoreStore+LoadStore屏障，并依托Owner切换形成强顺序锚点，实现块级有序。

很多人以为 synchronized 的有序性就是“加个锁、大家排队执行”，其实没那么简单。它的底层靠的是内存屏障（Memory Barrier）跟 JVM 对 Monitor 的语义约束，一边限制指令重排的范围，一边保证临界区里的操作，在其他线程眼里呈现出可预测的顺序。这才是它真正干活的方式。

有序性本质：禁止特定范围的指令重排

Ja va 允许编译器和 CPU 在单线程语义不变的前提下，自由调整指令顺序——这对单线程没问题，但多线程一上，就容易翻车。synchronized 并没有一刀切禁用所有重排，而是在进入和退出同步块时，悄悄插了两道防线：

• monitorenter 前：插 LoadLoad + LoadStore 屏障，目的是防止临界区内的读/写被提前到锁获取之前执行
• monitorexit 后：插 StoreStore + LoadStore 屏障，防止临界区内的写操作被拖到锁释放之后才生效

这样一来，同步块内部的代码，本线程看起来是按源码顺序跑；其他线程只要也通过同一把锁进入临界区，就能看到这些操作以跟书写顺序一致的方式发生——说白了，就是靠屏障把重排掐死在了入口和出口。

Monitor 机制强化执行边界

每个 synchronized 块或方法都会关联一个 Monitor。JVM 明确约定：线程只有成为 Monitor 的 Owner 才能执行临界区代码；而 Owner 切换本身就是一个天然的同步点。这就在锁的获取和释放之间，形成了两个强顺序锚点：

• 前一个线程释放锁（Owner 置空）→ 后一个线程获取锁（Owner 更新）→ 后一个线程才能开始执行
• 这个顺序由 JVM 跟操作系统协作保障，无法被绕过或者乱序

所以，“锁获取→执行→锁释放”这三个阶段串在一起，把多个线程对同一临界区的访问变成了串行化效果——宏观上，看起来就是逻辑上的顺序执行。

与 volatile 的有序性区别

volatile 只往变量读写处插轻量级屏障（LoadLoad / StoreStore），只约束跟那个变量相关的重排；而 synchronized 的屏障覆盖整个临界区，所有读写操作都被包在里面，还附带互斥语义。区别很明显：

• volatile 能禁止变量读之后任意读写的重排，但保证不了 i++ 这样的复合操作是不是原子
• synchronized 直接把整段代码打包成一个不可分割的执行单元——既禁重排，又保原子，还强可见

一句话总结：synchronized 的有序性是“块级有序”，volatile 是“字段级有序”。两者的粒度完全不是一个量级。

字节码与运行时协同生效

编译阶段，synchronized 块被翻译成 monitorenter / monitorexit 指令；到了运行期，JVM 在解释或 JIT 编译时，会根据锁的状态（偏向锁、轻量级锁、重量级锁）动态注入对应的屏障指令。举个例子：

• 轻量级锁基于 CAS 和栈帧中的 Lock Record，屏障由 HotSpot 内部硬编码插入
• 重量级锁依赖 OS 的 mutex，系统调用本身就带全内存屏障语义

无论锁处于哪种状态，JVM 都会保证有序性的语义不丢失——这正是 synchronized 能成为可靠同步手段的底层根基之一。说穿了，它不只是“加锁”，而是从字节码到运行时都帮你兜底。