volatile写操作通过MESI协议将本核缓存行置为Modified状态并广播Invalid消息，使其他核缓存失效；读操作因缓存缺失被迫从主内存或修改核重新加载最新值，从而保证可见性。
volatile 写操作触发 MESI 状态变更
volatile 的写不会“主动”刷新到主内存，而是通过 CPU 缓存一致性协议（主要是 MESI）强制让其他核心的缓存副本失效，从而间接迫使后续读取必须重新加载最新值。关键动作发生在写入当前核心缓存行时：Modified 状态被标记，同时广播 Invalid 消息给其他核心。
这个过程不依赖“把数据刷回主内存”这一步本身是否完成，而是依赖 MESI 的状态机约束：一旦某个缓存行进入 Modified 状态，该核心就成为该数据的唯一权威来源；其他核心再访问时，必须通过总线请求（Bus Request）从它这里获取——哪怕只是读，也可能触发写回（Write-Back）或直接转发（Intervention），具体取决于 CPU 实现。
- 不是所有 volatile 写都立即落盘或写入主内存；x86 下更常见的是写入 L1d 缓存并标记为
Modified - 主内存更新可能延迟发生（比如在缓存行被逐出时才写回），但可见性已由 MESI 的失效机制保障
- ARM 或 RISC-V 等架构无隐式总线锁，需依赖
DMB/DSB等显式内存屏障配合缓存一致性协议
LOCK 前缀指令是 x86 上的实现锚点
JVM 对 volatile 变量的写操作，在 x86 平台最终会编译为带 LOCK 前缀的指令（如 LOCK XCHG、LOCK ADD DWORD PTR [rax], 0）。这不是为了加锁，而是为了触发两个硬件级副作用：
- 使当前缓存行进入
Modified状态（满足 MESI 要求） - 发起总线锁定或缓存锁定（Cache Locking），确保该操作原子且能被其他核心嗅探到
没有 LOCK，普通写指令可能只更新本地缓存而不广播，其他核心无法感知变更——这就是普通变量不可见的根本原因。
读屏障如何配合 MESI 保证“看到最新值”
volatile 读操作前插入的 Load Barrier，在 x86 上通常不生成额外指令（因 x86 内存模型本身较严格），但它在语义上要求 JVM 确保：读取前检查缓存行状态；若为 Invalid，则阻塞直到完成缓存同步（例如通过总线事务拉取最新值）。
这和 MESI 的协作体现在：当写端广播失效后，读端的下一次访问必然触发缓存缺失（Cache Miss），CPU 自动发起请求，从拥有 Modified 状态的核心或主内存加载数据——Load Barrier 就是告诉 JVM：“别优化掉这次真实内存访问”。
- 若省略读屏障，JIT 可能将多次
volatile读合并为一次（尤其在循环中），导致永远读不到新值 - 即使缓存行状态是
Shared，读屏障也禁止编译器/处理器把后续读操作重排序到它前面
嵌入式与非 JVM 场景下 volatile 的差异
在裸机或 C 语言嵌入式开发中，volatile 仅影响编译器行为（禁止寄存器缓存、禁止重排序），不生成内存屏障指令，也不触发 MESI——因为单核 MCU 可能根本没缓存，或多核系统未启用缓存一致性协议。
这意味着：
- 在 ARM Cortex-M 系列（无缓存或无一致性协议）上，
volatile只防编译器优化，不解决多核可见性 - 在 Linux 用户态程序中，
volatile对线程间通信基本无效，必须配合pthread_mutex_t或 C11atomic才能保证同步 - JVM 的
volatile是软硬协同设计：JIT 生成屏障指令 + CPU 执行 MESI 协议 = 可见性保证
MESI 不是银弹，它只管缓存行粒度的一致性；而 volatile 的语义边界在 JMM 中定义清晰——别指望它保护复合操作，也别在非 x86 架构上默认它有 LOCK 效果。
