3. MESI协议详解：Modified、Exclusive、Shared、Invalid四种状态

大家好，我是你们的CPU架构设计讲师。今天我们来聊聊缓存一致性协议里最经典的一个——MESI协议。

说实话，MESI协议是我个人最喜欢的协议之一。为什么？因为它简单、优雅，而且在实际芯片中应用极广。我在做某款服务器CPU项目时，就亲自参与过MESI协议的硬件实现。嗯，那会儿踩过的坑，今天一并分享给你们。

3.1 四种状态：M、E、S、I

MESI协议把缓存行（Cache Line）分成四种状态。你想想看，这就像给每个缓存行贴了个标签，告诉别的核：「我这行数据现在是什么情况」。

状态	全称	含义	数据是否有效	与主存是否一致
M	Modified	已修改，且独占	有效	不一致（脏数据）
E	Exclusive	独占，未修改	有效	一致
S	Shared	共享，未修改	有效	一致
I	Invalid	无效	无效	—

我来逐一解释一下：

• Modified（M）：这个缓存行被当前核修改过，而且只有当前核拥有它。主存里的数据已经「过时」了。说白了，这行数据是「脏」的，其他核想读？得先让我写回主存。
• Exclusive（E）：当前核独占这行数据，但还没改过。主存数据是新鲜的。这个状态很特别——只有你一个人有，别人都没有。我在项目中遇到过，很多新手会忽略E状态和S状态的区别，结果总线事务发多了，性能白白浪费。
• Shared（S）：多个核都持有这行数据的副本，大家都没改过。主存数据是新鲜的。谁想写？得先通知其他人把副本作废。
• Invalid（I）：这行数据无效，相当于缓存里没这东西。读的话得去主存或者别的核那里拿。

3.2 状态转换图

下面这张图是我亲手画的MESI状态转换图。你仔细看，每个箭头都代表一次总线事务或本地操作。

这张图怎么看？我教你一个口诀：「读共享，写独占，别人读写我作废」。

• 从I出发：本地读，如果其他核没有副本，就变成E；如果有副本，就变成S。本地写，直接变成M（但需要总线事务通知别人）。
• 从E出发：本地写，变成M。其他核读，变成S。其他核写，变成I。
• 从S出发：本地写，变成M（同时发总线事务作废其他副本）。其他核写，变成I。
• 从M出发：其他核读，先把数据写回主存，然后变成S。其他核写，先把数据写回主存，然后变成I。

3.3 总线嗅探机制

MESI协议能工作，全靠总线嗅探（Bus Snooping）。说白了，每个核的缓存控制器都在「偷听」总线上的事务。

总线嗅探有两种常见实现方式：

1. 写无效（Write-Invalidate）：某个核要写数据时，在总线上广播一个「作废」消息。其他核收到后，把对应的缓存行标记为I。MESI用的就是这种方式。
2. 写更新（Write-Update）：某个核写数据时，直接把新数据广播给所有核。这种方式总线流量太大，实际芯片很少用。

我在项目中遇到过一个问题：总线嗅探的延迟如果太大，会导致整个系统性能急剧下降。你想想看，每个核都在监听总线，总线事务一多，仲裁器就忙不过来了。

3.4 实际应用中的注意事项

MESI协议虽然经典，但也不是万能的。我总结了几条实战经验：

• 伪共享（False Sharing）：两个核操作不同的变量，但这两个变量恰好在同一个缓存行里。结果MESI协议会让这个缓存行在多个核之间频繁失效。性能直接崩掉。解决办法？做缓存行对齐（Cache Line Padding）。
• 总线风暴：如果多个核频繁写同一个缓存行，总线事务会爆炸。我曾经见过一个数据库场景，因为锁竞争导致MESI协议在M和I之间疯狂切换，CPU利用率不到10%。
• E状态的利用：尽量让数据保持在E状态，这样写操作不需要总线事务。怎么做？减少数据共享，或者用线程本地存储。

好了，MESI协议就讲到这里。下一节我们会深入讨论MOESI和MESIF协议，看看它们怎么解决MESI的一些痛点。嗯，到时候我会分享一个我在服务器CPU项目中用MOESI协议优化性能的真实案例。

---

公众号:蓝海资料掘金营，微信deep3321