volatile写通过storestore+storeload屏障强制刷回主内存并使其他缓存失效，读通过loadload+loadstore屏障强制从主内存加载最新值，协同mesi协议实现可见性。
Java 中 volatile 的可见性，不是靠“魔法”实现的，而是 JVM 基于 Java 内存模型（JMM）规则，在编译和运行时主动插入内存屏障指令，强制线程与主内存同步数据，并协同底层硬件（如 CPU 缓存协议）共同完成的。
volatile 写操作如何让其他线程立即“看见”
当一个线程对 volatile 变量执行写操作（比如 flag = true），JVM 不只是把值存进当前线程的工作内存，而是严格按 JMM 规则做两件事：
- 在写操作之后立即插入 StoreStore + StoreLoad 内存屏障；
- StoreStore 确保该 volatile 写之前的所有普通写操作都已完成并刷出；
- StoreLoad 是最关键的屏障：它强制将当前 volatile 写的结果刷新到主内存，并且使其他 CPU 缓存中该变量对应的缓存行失效（配合 MESI 协议）；
- 这就意味着，其他线程下次读取该变量时，无法命中旧缓存，必须从主内存重新加载最新值。
volatile 读操作如何保证拿到“最新值”
当一个线程读取 volatile 变量（比如 while (!flag)），JVM 同样不会直接用工作内存里的副本，而是：
- 在读操作之前插入 LoadLoad + LoadStore 内存屏障；
- LoadLoad 阻止该读操作与后续其他读操作重排序，确保“先读 volatile，再读别的”；
- LoadStore 确保该 volatile 读操作一定在后续普通写操作之前完成；
- 更重要的是，该读操作会触发 CPU 从主内存（或通过缓存一致性协议获取）拉取最新值，覆盖当前线程工作内存中的旧副本。
内存屏障如何与硬件协同起作用
内存屏障本身是 JVM 生成的特殊指令（如 x86 上的 mfence、lfence、sfence），它不只是告诉 JVM “别乱序”，更关键的是向 CPU 发出信号：
- 写屏障（如 StoreLoad）会触发写回（write-back）和缓存行失效（invalidate）；
- 读屏障（如 LoadLoad）会触发缓存同步（cache coherency）检查，确保读到的是全局最新状态；
- 这些行为依赖底层硬件支持，例如 Intel 的 MESI 协议能自动维护多核间缓存一致性，而 volatile 正是借助这套机制落地可见性。
JMM 的 happens-before 规则提供语义保障
除了底层指令，JMM 还从抽象层面定义了明确的顺序约束：
- 对一个 volatile 变量的写操作 happens-before 任意后续对该变量的读操作；
- 这个规则不依赖具体执行时间，而是作为编译器优化和处理器调度的硬性边界；
- 它让程序员可以基于逻辑顺序推理并发行为，而不必纠结 CPU 流水线或缓存延迟等细节。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
