volatile 可见性依赖 cpu 硬件的 mesi 协议与总线嗅探机制：当写 volatile 变量时，触发 rfo 请求使其他核缓存行置为 invalid；读时若状态为 invalid 则强制重新加载，结合内存屏障确保写缓冲刷新与读操作有序，从而实现跨线程可见性。
Java 中 volatile 保证可见性，底层依赖的是 CPU 硬件级的缓存一致性机制，核心是 MESI 协议 和 总线嗅探（Bus Snooping）。它不是 JVM 单独实现的“软件魔法”，而是 Java 语言规范借用了现代多核 CPU 的硬件能力。
MESI 协议如何管理缓存状态
MESI 是四种缓存行（Cache Line）状态的缩写，每个 CPU 核心的缓存中，对应主内存某块数据的缓存行都处于其中一种状态：
- M（Modified，已修改）：该缓存行只存在于当前核心，且内容已被修改，与主内存不一致；必须在被替换前写回主内存。
- E（Exclusive，独享）：该缓存行只存在于当前核心，且与主内存一致；可直接修改，无需通知其他核。
- S（Shared，共享）：该缓存行可能存在于多个核心中，且所有副本与主内存一致；若要写入，需先升级为 M 状态。
- I（Invalid，无效）：该缓存行内容失效，下次读取必须从主内存或其它核心重新加载。
当一个线程写 volatile 变量时，JVM 会插入 StoreLoad 内存屏障，并生成带 LOCK 前缀的汇编指令（如 lock xchg）。这会触发 CPU 将对应缓存行状态从 S 或 E 转为 M，并向总线广播 RFO（Read For Ownership）请求。
总线嗅探让其他核心“感知变化”
每个 CPU 核心都持续监听（即“嗅探”）总线上的内存事务。一旦收到 RFO 请求，其它核心会检查自己缓存中是否含有同一地址的缓存行：
- 若有且处于 S 状态 → 立即置为 I（Invalid）；
- 若有且处于 M 或 E 状态 → 先写回主内存（或通过缓存直连同步），再置为 I；
- 之后，发起写操作的核心才能独占该缓存行并完成写入，再将结果刷新到主内存。
这意味着：其他线程下一次读这个 volatile 变量时，发现本地缓存行是 I 状态，就必须从主内存（或最新更新的缓存）重新加载——从而看到最新值。
为什么单纯靠 MESI 还不够？内存屏障补上关键一环
MESI 解决了“缓存之间同步”的问题，但现代 CPU 还有写缓冲器（Write Buffer）和无效队列（Invalidation Queue），它们会延迟实际的写入或失效操作，导致“看似同步却未生效”。这时仅靠协议本身无法严格保证 JMM 定义的 happens-before 关系。
-
volatile写操作后插入 StoreStore + StoreLoad 屏障，强制刷空写缓冲器，确保修改对其他核可见； -
volatile读操作前插入 LoadLoad + LoadStore 屏障，避免后续读/写提前执行，也防止读到过期缓存（即使状态还没来得及变 I）； - 这些屏障最终映射为 CPU 指令（如
mfence、lfence），协同 MESI 实现“写即可见、读即最新”。
一个典型场景还原
假设线程 A 在 CPU0 上执行 flag = true（flag 是 volatile）：
- CPU0 发出 RFO 请求，总线广播；
- CPU1 嗅探到该地址请求，将其本地 flag 缓存行标记为 I；
- CPU0 将 true 写入缓存行（M 状态），随后刷新到主内存；
- 线程 B 在 CPU1 上执行
while(!flag)，发现 flag 缓存行是 I，于是从主内存加载新值 true —— 循环退出。
整个过程没有锁、不阻塞调度，但依靠硬件协议与内存屏障的配合，实现了轻量级的跨线程可见性保障。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
