4、MESI状态转换：读请求、写请求下的状态变迁图与总线事务

好，咱们今天聊点硬核的。MESI协议，说白了就是四个状态怎么在CPU核之间跳来跳去。你光背状态定义没用，得搞清楚：什么时候变？谁触发的？总线上发生了什么？

我个人习惯，把MESI的状态转换分成两大类：本地请求和远程请求。本地请求是你这个核自己发起的读写，远程请求是别的核在总线上搞事情，你被动响应。

4.1 状态转换全景图

先给你一张总图，心里有个框架。每个状态（M/E/S/I）在收到读请求或写请求时，都会跳到另一个状态。同时，总线事务也会随之产生。

当前状态	事件	下一状态	总线事务	说明
I（无效）	本地读	S 或 E	BusRd	看其他核有没有副本，有则S，无则E
	本地写	M	BusRdX	通知所有人：我要独占写
S（共享）	本地读	S	无	读命中，啥事没有
	本地写	M	BusRdX	需要升级，让其他核失效
	远程读	S	无（或Flush）	如果数据脏，需要写回
E（独占）	本地读	E	无	读命中，继续独占
	本地写	M	无	直接改，不需要通知别人
	远程读	S	Flush	数据是干净的，但需要共享
M（修改）	本地读/写	M	无	独占且脏，随便操作
	远程读	S	Flush+Invalidate	必须写回内存，再共享出去

嗯，这张表你得刻在脑子里。我当年调一个多核性能问题，就是靠这张表一步步推演，才发现是某个核的缓存行一直卡在S状态没升级，导致写延迟暴增。

4.2 读请求下的状态变迁

先看读请求。读请求分两种：本地读和远程读。

4.2.1 本地读命中

如果缓存行在M、E、S状态，本地读直接命中。CPU从缓存拿数据，总线上一声不吭。这是最快的路径。

4.2.2 本地读缺失（I状态）

缓存行在I状态，说明你手里没数据。这时候CPU会发一个BusRd事务到总线上。

• 其他核都没有副本：总线嗅探器发现没人响应，数据从内存取。缓存行进入E状态（独占）。
• 其他核有S或E状态副本：那个核会响应，数据从它的缓存传给你。缓存行进入S状态（共享）。
• 其他核有M状态副本：那个核必须先把脏数据写回内存（Flush），然后数据再传给你。缓存行进入S状态。

这里有个坑，我曾经遇到过：M状态写回和BusRd的时序问题。如果两个核同时发起请求，总线仲裁器必须保证M状态的写回先完成，否则你会读到旧数据。嗯，硬件设计上这叫「总线事务排序」。

4.2.3 远程读请求（别人读你的缓存）

当别的核发BusRd时，你的缓存控制器会嗅探到。根据你当前的状态，反应不同：

• M状态：你手里是唯一且脏的副本。你必须把数据写回内存（Flush），然后你的状态变成S。因为别人也要读，你们共享。
• E状态：你手里是唯一但干净的副本。你不需要写回内存（因为内存已经是最新的），但你要把数据提供给对方。你的状态变成S。
• S状态：你手里是共享副本。你直接提供数据给对方，状态不变，还是S。
• I状态：你没数据，不关你事。

4.3 写请求下的状态变迁

写请求比读请求复杂。因为写操作意味着你要「独占」这块数据，别人不能有副本。

4.3.1 本地写命中

• M状态：直接写，状态不变。最快。
• E状态：直接写，状态变成M。因为你是唯一的，不需要通知别人。
• S状态：不能直接写！因为别人也有副本。你必须发BusRdX事务，让所有其他核把该缓存行置为I状态。然后你的状态变成M。

你想想看，S状态写命中为什么还要发总线事务？因为你要「升级」为独占。这个BusRdX事务会强制其他核的S状态变成I。如果其他核的缓存行是M状态，它必须先写回内存，再变成I。

4.3.2 本地写缺失（I状态）

缓存行不在你手里。CPU发BusRdX事务。这个事务的意思是：「我要写这块数据，你们谁有都得交出来，然后全部失效。」

• 其他核如果有M或E状态，必须写回内存（Flush）并变成I。
• 其他核如果有S状态，直接变成I。
• 数据从内存或某个核的缓存传给你，你的状态变成M。

4.3.3 远程写请求（别人要写你的缓存）

当别的核发BusRdX时，你的缓存行如果命中，必须无条件失效：

• M状态：先写回内存（Flush），再变成I。这是最重的操作。
• E或S状态：直接变成I。不需要写回，因为数据是干净的。
• I状态：不关你事。

4.4 总线事务详解

MESI协议里，总线事务就是CPU核之间的「通信语言」。主要有三种：

事务名称	发起者	含义	响应者行为
BusRd	读缺失的核	我要读这块数据，你们谁有？	有副本的核提供数据，M状态需Flush
BusRdX	写缺失或写升级的核	我要独占写，你们全部失效	所有核失效，M状态需Flush
Flush	被嗅探到的M状态核	我把脏数据写回内存	内存更新，总线监听者知道数据已写回

我记得有一次，团队里新来的同事问我：「Flush和BusRdX哪个先发生？」

答案是：看场景。如果是远程读请求命中M状态，先Flush再响应BusRd。如果是远程写请求命中M状态，先Flush再让出总线控制权给BusRdX。顺序不能乱，否则数据一致性就崩了。

4.5 状态转换图（文字版）

给你一个简化的状态机描述，方便你手画：

I状态：
  - 本地读 -> 发BusRd -> 进入S或E
  - 本地写 -> 发BusRdX -> 进入M
  - 远程读/写 -> 不变

S状态：
  - 本地读 -> 不变
  - 本地写 -> 发BusRdX -> 进入M
  - 远程读 -> 不变（提供数据）
  - 远程写 -> 进入I

E状态：
  - 本地读 -> 不变
  - 本地写 -> 进入M（不发总线事务）
  - 远程读 -> 进入S（提供数据）
  - 远程写 -> 进入I

M状态：
  - 本地读/写 -> 不变
  - 远程读 -> Flush -> 进入S
  - 远程写 -> Flush -> 进入I

嗯，这个图你最好自己画一遍。我当年学MESI时，就是在白板上画了不下50遍，才把每个箭头背后的总线事务记牢。

4.6 实战中的常见问题

• 伪共享（False Sharing）：两个核各自写不同的变量，但变量在同一个缓存行里。结果就是频繁的BusRdX和失效，性能暴跌。我曾经在一个高并发系统中，把两个热点变量用padding隔开，性能提升了3倍。
• 写回风暴：多个核同时写同一个缓存行，导致M状态频繁Flush。解决方案是减少锁竞争，或者使用本地累积再批量写回。
• 总线带宽瓶颈：BusRd和BusRdX事务太多，总线成为瓶颈。这时候可以考虑增大缓存行大小，或者优化数据布局。

好了，MESI的状态转换就讲到这里。下一章我们会深入总线嗅探机制，看看硬件是怎么「偷听」总线事务并做出反应的。到时候我会分享一个我亲手踩过的坑——总线事务丢失导致的数据不一致。