volatile语义统一但硬件实现不同：x86靠lock指令天然强序，ARM需显式dmb屏障（ishst/ishld）补足弱内存模型，二者均通过对应内存屏障兑现JMM规范的StoreStore/StoreLoad及LoadLoad/LoadStore约束。
Java 中 volatile 在多核环境下表现一致，但底层实现和重排序约束能力因 CPU 架构而异——x86 天然强序，ARM 默认弱序，volatile 语义必须靠不同硬件屏障补足。理解差异的关键不是“volatile 是否工作”，而是“它在每种架构上靠什么机制兑现承诺”。
volatile 的语义是统一的，硬件实现却有根本区别
Java 内存模型（JMM）对 volatile 的规范是固定的：写操作建立 StoreStore + StoreLoad 屏障，读操作建立 LoadLoad + LoadStore 屏障。但 JVM 不会直接发射“内存屏障指令”，而是根据目标 CPU 插入对应汇编：
-
x86 架构：volatile 写通常编译为
lock xchg或lock addl，隐含全屏障（Full Barrier），天然满足 StoreStore 和 StoreLoad；volatile 读就是普通mov，因 x86 本身禁止 Load-Load 和 Load-Store 重排，无需额外指令。 -
ARM64 架构：volatile 写需显式插入
dmb ishst（内部共享存储屏障）+dmb ishld（内部共享加载屏障）或等效组合；volatile 读需dmb ishld，否则无法阻止后续读被提前——ARM 不保证读写顺序，必须靠指令强制。
重排序风险在 ARM 上更易暴露
典型场景：data = 42; ready = true;（非 volatile）。在 x86 上，即使无同步，ready == true 时 data 几乎总是 42；但在 ARM 上，ready 可能先刷到其他核心缓存，而 data 还卡在本地 store buffer 中，导致其他线程看到 ready == true 却读到 data == 0。
加 volatile 后：
立即学习“Java免费学习笔记（深入）”；
- x86：靠 lock 指令把
data = 42刷出并阻塞后续读，逻辑自然成立； - ARM：靠
dmb ishst确保data写完成后再发ready，再靠dmb ishld让读ready后的data不被提前——两道屏障缺一不可。
开发者不能假设“volatile 读就一定看到最新值”
尤其在 ARM 上：
- 仅靠 volatile 读（如
if (flag) { return data; }）不能 100% 保证读到data的最新值，除非写端也用 volatile（或 release 语义）配对； - 旧版 ARMv7 缺少严格 acquire 语义支持，JVM 必须插入更强的
dmb ish，而 Java 9+ 的VarHandle.getAcquire()才明确表达该意图； - 高频读 volatile 布尔标志位在 ARM 上比 x86 更敏感，因为每次读都带 dmb 开销，而 x86 是零成本 mov。
双检锁单例中 volatile 的作用，在两种架构下本质相同但路径不同
instance = new Singleton(); 被 volatile 修饰，防止构造过程重排为“分配内存 → 写 instance → 初始化对象”。这个约束在两种架构下都生效，但保障方式不同：
- x86：lock 指令让写
instance成为一个原子发布点，所有前置写（包括对象字段初始化）必然在此前完成； - ARM：JVM 插入
dmb ishst强制 store buffer 刷出，并配合 cache 一致性协议（如 MESI）确保其他核心看到写后能获取完整初始化状态。
