CAS 本身不直接禁止编译器重排，而是依赖 volatile 变量的内存屏障语义和 CPU 原子指令的全内存屏障共同保障有序性；volatile 锁定指令顺序，CAS 将读-比-写三步打包为不可分割的原子操作。
CAS 机制本身不直接“确保”不被编译器重排，而是通过与 volatile 变量配合 + CPU 硬件指令保障，共同构成一道有序性防线。关键在于：CAS 操作的目标变量必须是 volatile 修饰的，而 volatile 的语义本身就禁止编译器对其读写做重排序。
volatile 是编译器重排的“刹车片”
Java 内存模型（JMM）规定：对 volatile 变量的每次读/写，都具有“内存屏障”语义。编译器在生成字节码时，会严格遵守以下约束：
- 不允许将 volatile 写操作与其前面的任何读写操作重排序（写屏障前移限制）
- 不允许将 volatile 读操作与其后面的任何读写操作重排序（读屏障后移限制）
- volatile 读与 volatile 写之间也不能重排序（读-写屏障）
例如 AtomicInteger 中的 value 字段被声明为 private volatile int value，这就锁定了围绕它的指令顺序——编译器不会把对 value 的 CAS 前置操作（如计算新值）挪到 volatile 写之后，也不会把后续依赖 value 结果的逻辑提前。
CAS 调用本身触发内存屏障指令
JVM 在底层调用 Unsafe.compareAndSwapInt 时，并非简单执行几条普通指令。它最终会映射为 CPU 的原子指令（如 x86 的 CMPXCHG），而该指令隐含全内存屏障（full memory barrier）效果：
立即学习“Java免费学习笔记（深入）”；
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 强制刷新当前 CPU 缓存行，使修改对其他核可见
- 禁止该指令前后的普通读写指令跨越它重排（包括编译器和 CPU 层面）
- 相当于在 CAS 调用前后各插入了一道不可逾越的“栅栏”
为什么单靠 volatile 不够？为什么还要 CAS？
volatile 解决的是可见性和部分有序性，但不保证复合操作原子性。比如 inc++ 即使作用于 volatile 变量，仍会被拆成读-改-写三步，中间可能被其他线程打断。
CAS 把“读取当前值 → 比较预期值 → 写入新值”这三步打包成一条 CPU 原子指令，且这条指令自带屏障。这样既避免了编译器把这三步拆开重排，又防止了多线程下因执行间隙导致的状态错乱。
典型协同场景：AtomicInteger.getAndIncrement()
其核心逻辑等价于：
do {
current = get(); // volatile 读，带读屏障
next = current + 1;
} while (!compareAndSet(current, next)); // CAS 调用，带全屏障
这里两个屏障叠加：volatile 读确保 current 是最新值且不会被重排到循环外；CAS 调用确保比较与交换不可分割、不被穿插，也阻止 next 的计算被错误地调度到 CAS 之后。
