MESI不能完全解决可见性，因Store Buffer和Invalidation Queue导致写传播与读同步存在时间窗口；volatile通过内存屏障强制刷空缓冲区并清空失效队列，确保修改立即进入缓存、读取必加载最新值。
可见性问题的根源不在 Java 本身，而在于硬件执行层——CPU 多级缓存与缓存一致性机制之间的张力。即使有 MESI 协议，线程间变量仍可能“看不见”，关键在于：协议保障的是最终一致性，而非即时可见性。
为什么 MESI 不能完全解决可见性？
MESI（Modified、Exclusive、Shared、Invalid）协议通过状态机协调多核缓存，确保某变量在任意时刻最多只有一个核能修改（M/E 状态），其他核缓存该变量时必须标记为 I（Invalid）。但问题出在两个硬件优化结构上：
- Store Buffer（写缓冲区）：CPU 写操作先入 Store Buffer，再异步刷入缓存行；期间其他核嗅探不到新值，仍可能从自己缓存读旧值
- Invalidation Queue（失效队列）：收到失效请求后不立即处理，而是排队等待空闲周期；导致本核读取时仍命中旧缓存行
这两个结构让“写→通知→刷新→读取”变成非原子链路，中间存在时间窗口——这就是可见性丢失的物理根源。
变量何时才算对其他线程“真正可见”？
一个变量的修改要被另一线程看到，需满足三个条件同时达成：
- 该修改已从 Store Buffer 刷入本核 L1 缓存，并将对应缓存行状态置为 M 或 E
- 本核已向总线广播 Invalidate 消息，且收到其他核的确认（Invalidate ACK）
- 目标核已完成 Invalid Queue 中的处理，将本地缓存行状态设为 I，并在下次读取时触发 Cache Miss，从本核缓存或主存重新加载
这个过程不是瞬间完成的，尤其在高负载或跨 NUMA 节点场景下，延迟可达数百纳秒甚至更长。
volatile 如何借力 MESI 实现可见性？
Java 的 volatile 不是凭空创造规则，而是精准调用硬件能力：
- 写 volatile 变量时，JVM 插入 StoreStore + StoreLoad 内存屏障，强制刷空 Store Buffer，使修改立即进入缓存行
- 读 volatile 变量时，插入 LoadLoad + LoadStore 屏障，清空本核 Invalid Queue 并触发 refresh，确保后续读取一定从最新缓存/内存加载
- 底层上，这相当于告诉 CPU：“此刻必须完成 MESI 协议中‘写传播’和‘读同步’两个环节”，绕过优化带来的不确定性
单核 CPU 上还有可见性问题吗？
有，但来源不同。单核不存在缓存一致性问题，但仍有：
- JIT 编译器优化：如将 while(!flag) 优化为 if(!flag) { while(true) { } }，因未观测到 flag 被其他线程修改
- 寄存器缓存：线程可能把 flag 值长期保留在寄存器中，不重新从栈或堆加载
- 指令重排序：编译器或 CPU 可能调整读写顺序，破坏逻辑依赖
volatile 同样抑制这些行为——它既是硬件同步指令，也是编译器契约。
