mesi协议是多核cpu缓存一致性的硬件保障机制，通过modified、exclusive、shared、invalid四种状态及总线监听实现跨核心数据同步。
多核 CPU 上的并发代码能正确运行，靠的不是语言或 JVM 的魔法，而是底层硬件在默默保障——MESI 协议就是那个关键守门人。它不依赖软件干预，而是通过每个核心实时监听总线上的内存访问信号，自动协调缓存行状态，确保所有核心看到的同一变量值始终一致。
为什么需要 MESI：缓存不一致是怎么发生的
现代 CPU 为缓解“CPU 快、内存慢”的鸿沟，普遍采用多级私有缓存（L1/L2）+共享缓存（L3）架构。当 Core A 和 Core B 同时读取变量 x=0，各自缓存中都存了一份副本；若 Core A 修改 x=1 并仅写入自己的 L1 缓存（写回策略），而未通知 Core B，后者下次读 x 仍得到 0——这就是典型的缓存不一致。
这类问题在并发编程中会直接表现为：
- volatile 变量写后，另一线程读不到新值
- 无同步的共享计数器结果小于预期
- 对象字段更新后，其他线程看到部分更新（字节错乱）
MESI 的四种状态与真实含义
MESI 不是抽象概念，而是每个缓存行实际维护的 2-bit 状态标记，直接决定该行能否被读/写，以及是否需要广播：
- Modified（M）：数据已修改，与主存不一致；且全系统仅本核心持有该最新值
- Exclusive（E）：数据与主存一致，且确认只有本核心持有（未被其他核心读过）
- Shared（S）：数据与主存一致，但可能被多个核心同时持有
- Invalid（I）：该缓存行无效，不可用；下次访问必须重新加载
注意：E 和 M 是精确状态（只有一份副本），S 是“可能共享”状态，I 是强制清空信号的结果。
监听总线如何触发状态转换
所有核心持续监听总线（Snooping），一旦检测到涉及自己缓存行的操作，立即响应。典型流程如下：
- Core A 读 x（Miss）→ 从内存加载，状态设为 E（首次独占）
- Core B 读 x（Miss）→ 也从内存加载，此时 A 和 B 都变为 S（共享）
- Core A 写 x → 发出 RFO（Request For Ownership）广播：“我要独占 x！”
- Core B 嗅探到 RFO → 将自己缓存中 x 标记为 I（失效）
- Core A 收到响应后 → 将 x 状态升为 M，并写入新值
后续 Core B 再读 x 时，因状态为 I，触发 Cache Miss，会向总线请求数据；此时 Core A 若仍持 M 状态，可直接响应（缓存直送），无需访问主存。
它和 Java volatile / synchronized 有什么关系
JMM（Java 内存模型）的语义建立在硬件能力之上。volatile 字段的写操作，在 x86 上会插入 lock 前缀指令，强制触发 MESI 的 RFO 流程，使其他核心缓存失效；synchronized 的加锁/解锁，则对应一次完整的 M→S→I→S 状态循环，保证临界区前后可见性。
换句话说：JVM 不创造一致性，只是把 MESI 提供的硬件能力，封装成程序员可用的语义边界。没有 MESI，volatile 就无法保证可见性；没有 MESI，synchronized 的原子性也无法在缓存层落实。
