想象一间大办公室：几十位员工共用一份放在公共文件柜里的《项目排期表》，为了效率，每个人工位上都有复印件。产品经理刚改了排期，实习生还在按旧复印件订会议室，另一位员工又把自己那份改了一版保存……办公室瞬间乱套。在计算机里，CPU 核心就像这些员工，主存是公共文件柜，缓存（Cache）就是工位上的复印件。多核 CPU 必须有一套规则，让每个人都知道“哪一版才是最新的”，才不会发生数据互相覆盖、谁也信不过谁的乱局。MESI 缓存一致性协议正是这样一套被写进硬件的“办公室协作规定”。它用四种状态给每份缓存副本贴标签，再靠一条共享总线广播消息，保证任何时刻任何核心读到的数据都是最新的。

岗位关联

对 AI 从业者来说，多线程推理、数据加载、容器调度都会跑到多核 CPU 上。理解 MESI，就是理解多线程性能瓶颈与诡异并发 Bug 的物理根源，能帮你从“调参”走向“调系统”。

目录
  1. 可视化演示
  2. 一致性问题
  3. MESI状态
  4. 状态转换
  5. 总线机制
  6. 写失效策略
  7. 性能优化
  8. 工程实践
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

演示4核心缓存行在MESI协议下的状态转换，通过模拟读写操作观察M/E/S/I四种状态如何在各核心间迁移，并统计总线动作与命中率。

本节配有交互动效（进入视口后自动加载，约 3KB）。

MESI 四状态 M修改：脏数据独家 E独占：干净独家 S共享：多核一致 I无效：需重载 写需独占 总线失效其余核

一致性问题

回到那间办公室：每位员工都想用最新的共享文件，但又都懒得每次去文件柜。于是工位上的复印件越攒越多，版本也越来越多。如果没有人规定“谁改完必须通知谁”，后改的人会把别人的更新悄悄覆盖掉。多核 CPU 也面临同样处境——每个核心都有自己的缓存，而它们共享同一个主存。高速缓存让单个核心变快，却让“多个版本”的问题变明显。

这个问题的本质是：同一个内存地址的数据，可能同时存在于主存和多个核心的缓存中，而且其中一份还可能被改过但还没写回主存。对程序员来说，最直观的后果就是“明明有人写了变量，另一个线程却读到了旧值”。MESI 缓存一致性协议就是为了解决这种“复制了多份，不知道哪份最新”的场景。

协议需要保证一条核心不变量：任意时刻，同一个地址只有一个“最新版本”，其他核心要么持有一致的干净副本，要么干脆标记为无效。MESI 把这句话变成硬件可执行的状态规则：

回到办公室，MESI 相当于钉死了一条铁律：真正被改动的那一份只能出现在一个人桌上，其他人手上的旧纸必须盖上“作废”章。有了这条铁律，大家才敢相信读到的数据。

∀x,  ∣{c:State(c,x)=M}∣≤1  ∧  (State(c,x)=M⇒∀d≠c,  State(d,x)=I)\forall x,\; \big| \{ c : \text{State}(c,x)=M \} \big| \le 1 \;\wedge\; \big( \text{State}(c,x)=M \Rightarrow \forall d \neq c,\; \text{State}(d,x)=I \big)
  1. 全称量词公式开头的 \(\forall x\) 表示“对每一个内存地址”，也就是这条规则不是针对某个特例。
    ∀x\forall x
  2. 计数条件\(\big| \{ c : \text{State}(c,x)=M \} \big| \le 1\) 表示在所有核心中，持有该地址 M 状态副本的核心数量最多只能是一个。
    ∣{c:State(c,x)=M}∣≤1\big| \{ c : \text{State}(c,x)=M \} \big| \le 1
  3. 互斥约束\(\text{State}(c,x)=M \Rightarrow \forall d \neq c,\; \text{State}(d,x)=I\) 表示一旦某个核心是 M，其他所有核心面对这个地址的状态都必须是 I，不能同时有有效副本。
    State(c,x)=M⇒∀d≠c,  State(d,x)=I\text{State}(c,x)=M \Rightarrow \forall d \neq c,\; \text{State}(d,x)=I
  4. 逻辑连接中间的 \(\wedge\) 表示“并且”，两个条件必须同时成立，协议才算正确。
    ∧\wedge

MESI状态

为了让员工一眼看清每份复印件“能不能用、能不能改”，办公室发明了四色便签。便签颜色就是缓存行的状态：红色代表已经被改过了，蓝色代表只有自己有且还没改，绿色代表好几个人都拿着同样干净的副本，灰色代表这张纸已经作废。计算机里的 MESI 协议，正是用 M、E、S、I 四种状态描述每一个缓存行的“身份”。

  • M（Modified）：当前核心修改过这个缓存行，数据是系统里最新的，而且没有别人持有副本。后续写命中不需要总线事务，但最终必须写回主存。
  • E（Exclusive）：当前核心持有唯一的干净副本，数据和主存一致。因为没有其他副本，之后写操作可以直接变成 M，连失效广播都不用发。
  • S（Shared）：多个核心持有干净副本，都和主存一致。读操作不需要总线，但写操作要先广播失效。
  • I（Invalid）：该缓存行中的内容已经过期或不存在，不能读也不能写，必须重新从总线或主存获取。

这四种状态可以形式化地写成：

四色便签是整套协议的地基。员工看到蓝色便签就知道“只有我有，可以放心改”；看到绿色便签就知道“改之前要喊一声”；看到红色便签就知道“我手里就是最新版”；看到灰色便签就干脆别费神。

\mathcal{S}=\{M,E,S,I\},\quadM \equiv \text{dirty} \wedge \text{unique},\;E \equiv \text{clean} \wedge \text{unique},\;S \equiv \text{clean} \wedge \text{shared},\;I \equiv \text{invalid}.
  1. 状态全集\(\mathcal{S}=\{M,E,S,I\}\) 表示协议中所有可能的缓存行状态只有这四种。
    S={M,E,S,I}\mathcal{S}=\{M,E,S,I\}
  2. M 的性质\(M \equiv \text{dirty} \wedge \text{unique}\) 表示 Modified 的缓存行是“被改过”且“唯一”的。
    M≡dirty∧uniqueM \equiv \text{dirty} \wedge \text{unique}
  3. E 与 S 的性质\(E \equiv \text{clean} \wedge \text{unique}\)，\(S \equiv \text{clean} \wedge \text{shared}\)，二者都是干净的，区别在于是“唯一”还是“共享”。
    E≡clean∧unique,  S≡clean∧sharedE \equiv \text{clean} \wedge \text{unique},\; S \equiv \text{clean} \wedge \text{shared}
  4. I 的性质\(I \equiv \text{invalid}\) 表示该缓存行已经不能继续使用。
    I≡invalidI \equiv \text{invalid}

状态转换

状态不是永远不变的。员工每次想读文件、想改文件，先看一眼便签颜色，再决定要不要去走廊吼一声。计算机里，这个“吼一声”就是发起总线事务。一个缓存行在本地请求和远程请求的影响下，会在 M、E、S、I 之间来回切换。

驱动状态转换的事件主要有四类：本地读 LR、本地写 LW、远程读 RR、远程写 RW。举例来说，一个 I 状态的行发生本地读缺失后，如果总线上没有其他核心持有副本，就进入 E；如果别人也有副本，就进入 S。一个 S 状态的行发生本地写时，要先广播失效，再进入 M。远程核心的读写，则会让当前核心主动提供数据或放弃副本。

可以用一组状态转移表达式概括：

有了这套状态机，员工不需要记复杂的因果，只需要在每次“听到广播”和“想要读写”时按流程行动。硬件控制器做的正是这件事。

LR(I)→E∨S;LW(E)→M;LW(I∨S)→M;RR(M∨E)→S;RW(M∨E∨S)→I.\begin{aligned}\text{LR}(I)&\to E \vee S; & \text{LW}(E)&\to M; \\\text{LW}(I \vee S)&\to M; & \text{RR}(M \vee E)&\to S; \\\text{RW}(M \vee E \vee S)&\to I.\end{aligned}
  1. 本地读失效\(\text{LR}(I)\to E \vee S\) 表示 I 状态遇到本地读时，可能变成 E，也可能变成 S，取决于总线上是否发现其他共享副本。
    LR(I)→E∨S\text{LR}(I)\to E \vee S
  2. 独占写升级\(\text{LW}(E)\to M\) 表示 E 状态本来就只有一份副本，本地写不需要通知任何人，直接升级为 M。
    LW(E)→M\text{LW}(E)\to M
  3. 失效后写\(\text{LW}(I \vee S)\to M\) 表示 I 或 S 状态要本地写时，需要发出读拥有权或失效广播，最终变成独占的 M。
    LW(I∨S)→M\text{LW}(I \vee S)\to M
  4. 远程读降级\(\text{RR}(M \vee E)\to S\) 表示远程核心要读这行数据时，当前核心要提供数据，然后降级为 S，因为此时双方都有一份。
    RR(M∨E)→S\text{RR}(M \vee E)\to S
  5. 远程写失效\(\text{RW}(M \vee E \vee S)\to I\) 表示只要别的核心写了这行，当前核心的有效副本都必须作废。
    RW(M∨E∨S)→I\text{RW}(M \vee E \vee S)\to I

总线机制

办公室里没有私聊通道，员工想确认谁有最新文件，只能靠走廊里的广播。类似地，多核 CPU 的核心之间通过共享总线通信。当一个核心发起读请求、读拥有权请求或失效请求时，这条消息会被广播给所有核心，每个核心的缓存控制器都竖起耳朵监听——这就是“总线嗅探”（Bus Snooping）。

总线嗅探让每个核心都能实时感知远程操作。例如核心 A 发起一个普通读请求，核心 B 如果发现自己持有 M 或 E 状态的行，就可以通过总线把数据发给 A，并把状态降为 S；如果没人响应，则由主存提供数据。核心 A 发起写请求时，其他核心听到后要把自己的副本置为 I，避免以后读到旧值。

一次缓存缺失的延迟由三段组成，可以写成：

广播机制实现简单，但代价是每个核心都要停下来听广播。办公室里人越多，走廊越堵；CPU 核数越多，总线上的一次事务就要被越多人监听，这也是广播型一致性协议在核数很多时性能下降的原因。

Tmiss=Tbus_req+Tsnoop_resp+TtransferT_{\text{miss}} = T_{\text{bus\_req}} + T_{\text{snoop\_resp}} + T_{\text{transfer}}
  1. 请求上总线\(T_{\text{bus\_req}}\) 是当前核心等待总线空闲并发出请求的时间。
    Tbus_reqT_{\text{bus\_req}}
  2. 嗅探响应\(T_{\text{snoop\_resp}}\) 是所有核心监听、判断并给出响应所花的时间。
    Tsnoop_respT_{\text{snoop\_resp}}
  3. 数据传送\(T_{\text{transfer}}\) 是真正把缓存行数据从主存或响应核心传到请求核心的时间。
    TtransferT_{\text{transfer}}

写失效策略

共享文件怎么同步？办公室里有两种思路：一种是员工改完文件后，先群发一条“你们手上的旧版作废”的通知，再慢慢改；另一种是每次改一个字，就把整份新文件群发给所有人。显然后者太浪费纸张。MESI 选择的是第一种思路，也就是“写失效”（Write Invalidate）。

当一个核心要写一个 S 状态的缓存行时，它会先广播失效消息，让其他核心的对应行都变成 I，然后自己独占修改为 M。之后只要它继续写这一行，因为已经是 M 状态，就不需要再发总线消息了。相反，如果采用写更新协议，每次写都会把新数据广播出去，连续写 k 次就要广播 k 次。

这两种策略的总线流量对比可以写成：

需要注意的是，一致性维护的粒度是整条缓存行，通常是 64 字节。假设核心 A 不断写变量 \(x\)，核心 B 不断写变量 \(y\)，而 \(x\) 和 \(y\) 恰好挤在同一缓存行里，那么两个逻辑上毫无共享的数据也会被 MESI 绑定在一起，产生频繁的失效广播。这就是后文要说的“伪共享”。

Trafficinv=RFO+0×(k−1),Trafficupd=k×WriteMsg\text{Traffic}_{\text{inv}} = \text{RFO} + 0 \times (k-1),\quad\text{Traffic}_{\text{upd}} = k \times \text{WriteMsg}
  1. 写失效的初始开销\(\text{RFO}\) 表示第一次写共享行时，需要发送一次“读拥有权”或失效请求。
    RFO\text{RFO}
  2. 后续写开销\(0 \times (k-1)\) 表示进入 M 状态后，剩余 \(k-1\) 次本地写都无需总线消息。
    0×(k−1)0 \times (k-1)
  3. 写更新的开销\(k \times \text{WriteMsg}\) 表示写更新协议中，每次写都要广播一次完整数据，总共 k 次。
    k×WriteMsgk \times \text{WriteMsg}

性能优化

写操作如果每次都等在走廊边，等所有同事回复“收到”，整个团队都会慢下来。于是办公室给每张工位放了一块留言板：员工想写共享文件时，先把内容写在留言板上，继续干自己的事，后台硬件再去广播失效。这块留言板在 CPU 里叫写缓冲器（Store Buffer）。

写缓冲器减少了写停顿，却也带来了新问题：其他核心可能暂时看不到留言板上的内容，造成“感觉上写操作没有生效”的乱序现象。因此硬件提供内存屏障指令，要求留言板上的内容必须在下一条操作之前真正广播出去。另一方面，MESI 也演化出了多种变体：MOESI 增加 Owned 状态，允许脏数据在多个缓存间传递而不必立刻写回；MESIF 增加 Forward 状态，指定唯一转发者，避免多个核心同时响应造成总线抢答。

衡量缓存性能时，一个经典指标是平均访存时间：

留言板不是万能药：它让写操作变快，却让读者偶尔看到旧数据。真正的系统设计，就是在效率与有序之间不断找平衡。

AMAT=HitTime+MissRate×MissPenalty\text{AMAT} = \text{HitTime} + \text{MissRate} \times \text{MissPenalty}
  1. 平均访存时间\(\text{AMAT}\) 表示平均访问一次内存要花的时钟周期。
    AMAT\text{AMAT}
  2. 命中时间\(\text{HitTime}\) 是缓存命中时访问数据的时间，通常很短。
    HitTime\text{HitTime}
  3. 缺失率与缺失代价\(\text{MissRate} \times \text{MissPenalty}\) 表示缺失发生的比例乘以每次缺失额外付出的代价。
    MissRate×MissPenalty\text{MissRate} \times \text{MissPenalty}

工程实践

再完美的办公室制度，也需要有人巡检。真实 CPU 里，MESI 由硬件缓存控制器自动执行，但工程师可以通过性能计数器观察它是否在“打架”。例如 cache-miss、snoop 相关事件突然飙升，往往说明多个核心正在同一缓存行上互相失效。

工程上最常见的优化手段有三类：第一，用结构体填充（padding）把高频访问的热变量分散到不同缓存行，消除伪共享；第二，用原子操作、锁和内存屏障保证多线程顺序；第三，在 ARM、x86 等不同体系结构下，留意写缓冲器带来的可见性差异。调试这类问题，常用的工具是 perf、VTune 等性能剖析工具，看的不只是 CPU 占用率，还有缓存一致性事件。

内存屏障背后的语义可以写成：

MESI 是硬件给多核世界立下的规矩。程序员懂得这些规矩后，写并发代码时就能解释那些“玄学”性能抖动，也能提前设计出更友好的数据结构。

mfence:  Store(Pi,x)≺bLoad(Pi,y)  ⇒  Store(Pi,x)≺vLoad(Pi,y)\text{mfence}:\; \text{Store}(P_i, x) \prec_b \text{Load}(P_i, y)\;\Rightarrow\;\text{Store}(P_i, x) \prec_v \text{Load}(P_i, y)
  1. 屏障指令\(\text{mfence}\) 是一条让内存操作强排序的屏障指令。
    mfence\text{mfence}
  2. 程序序\(\text{Store}(P_i, x) \prec_b \text{Load}(P_i, y)\) 表示在核心 \(P_i\) 的程序顺序里，写 \(x\) 发生在读 \(y\) 之前。
    Store(Pi,x)≺bLoad(Pi,y)\text{Store}(P_i, x) \prec_b \text{Load}(P_i, y)
  3. 可见序\(\Rightarrow\) 后面说明有了 mfence 后，写 \(x\) 也会在可见顺序上先于读 \(y\)，其他核心不会看到颠倒的结果。
    Store(Pi,x)≺vLoad(Pi,y)\text{Store}(P_i, x) \prec_v \text{Load}(P_i, y)

AI 应用场景

多线程推理引擎性能调优

阶段：模型推理部署与性能优化

解决的问题：AI 推理框架（如 ONNX Runtime、PyTorch CPU 推理）会启动多个线程并行处理同一个 batch。如果两个线程频繁更新位于同一缓存行内的统计变量，MESI 会不断广播失效，导致缓存“乒乓”。理解 MESI，工程师就能通过字段填充、数据对齐等手段避免伪共享，把推理延迟降下来。

具体案例：在 CPU 端优化一个实时检测模型时，每个线程维护自己的 batch 统计量，初始结构体里 16 个计数器挤在同一缓存行，吞吐只有 120 次/秒；将统计量按缓存行填充后，吞吐提升到 150 次/秒。定位手段就是 perf 中观察到剧烈增长的 cache-miss。

数据并行训练的数据加载优化

阶段：训练数据预处理流水线

解决的问题：PyTorch DataLoader 的多进程 Worker 会把预处理好的数据放进共享内存队列，计算进程再从队列取 batch。多个进程同时读写队列头尾，容易共享同一缓存行，触发不必要的失效广播，让“取数据”变成瓶颈。MESI 知识能指导设计无锁队列、合理设置 num_workers 与 pin_memory，减少跨核缓存抖动。

具体案例：在大规模图片训练中，DataLoader 的 Worker 数从 4 调到 16，训练 step 延迟反而上升。通过性能计数器发现共享批索引的缓存行被反复失效，把索引改为每 Worker 本地缓存并按 64 字节对齐后，训练吞吐恢复平稳。

Python 演示

python72 行
class Bus(object):    def __init__(self):        self.caches = []     def attach(self, cache):        self.caches.append(cache)     def read_request(self, requester):        data_from_cache = False        for c in self.caches:            if c is not requester and c.state in ("M", "E"):                requester.value = c.value                c.state = "S"                data_from_cache = True        if not data_from_cache:            requester.value = 0        shared = any(c is not requester and c.state in ("S", "E", "M") for c in self.caches)        requester.state = "S" if shared else "E"        return requester.state     def write_invalidate(self, requester):        for c in self.caches:            if c is not requester:                c.state = "I"  class MESICache(object):    def __init__(self, bus):        self.bus = bus        self.state = "I"        self.value = 0        if bus is not None:            bus.attach(self)     def read(self):        if self.state == "I":            self.bus.read_request(self)        return self.value     def write(self, value):        if self.state in ("I", "S"):            if self.state == "I":                self.bus.read_request(self)            self.bus.write_invalidate(self)            self.state = "M"        else:            self.state = "M"        self.value = value  def trace(caches):    print([c.state for c in caches])  def main():    bus = Bus()    core0 = MESICache(bus)    core1 = MESICache(bus)     trace([core0, core1])    core0.read()    print("after core0.read:", core0.state, core1.state)    core1.read()    print("after core1.read:", core0.state, core1.state)    core0.write(42)    print("after core0.write:", core0.state, core1.state)    core1.read()    print("after core1.read:", core0.state, core1.state, core1.value)  if __name__ == "__main__":    main()
目的：用 30 行左右的状态机模拟两个核心在 MESI 协议下的读、写与失效广播，输出每一步的状态变化，演示 E→S→M→I 的典型转换轨迹。
  1. bus.read_request(self)发起一次总线读请求，其他核心如果持有 M/E 会提供数据并降为 S。
  2. shared = any(...)检查总线上是否还有其他有效副本，决定当前核心进入 E 还是 S。
  3. bus.write_invalidate(self)发起写失效广播，让其他核心的对应缓存行全部变成 I。
  4. if self.state == "I": self.bus.read_request(self)对无效行写之前，需要先通过总线拿到数据，再执行失效。
  5. core1.read()此时核心 0 已经是 M 状态，read_request 会让核心 0 把数据传给核心 1，两者一起变成 S。

常见误区

误区我以为 MESI 和缓存命中率优化一样，是让单核 CPU 跑得更快的技巧，多核才需要用到它。

正解单核 CPU 只有一份缓存，不存在“多个缓存副本互相冲突”的问题，也就不需要一致性协议。MESI 专门用于多核共享主存的场景：每个核心都有自己的缓存，协议负责让这些缓存副本保持一致。就像办公室里如果只有一个人看文件，根本不需要“版本作废”广播。

为何常见：学习内存层次时，大家先学 Cache 对性能的提升，再学 MESI，容易误以为它是缓存性能优化手段。

误区我觉得“缓存一致性”就是“内存一致性”，两者都是保证多线程看到最新数据。

正解MESI 解决的是“同一个地址”在不同缓存中的值一致性问题，比如地址 X 被改过，所有核心再读 X 都能拿到新值。内存一致性模型讨论的是“不同地址”的读写顺序，比如先写 A 再写 B，其他核心能不能看到 B 先于 A。而且写缓冲器还可能让写操作暂时不可见，MESI 本身不负责修复这种乱序。

为何常见：两个概念都涉及“可见性”和“顺序”，名字又很像，初学者很容易混在一起。

误区我看到 S 状态写之前要广播失效，就以为 MESI 里每次写操作都会占用总线，写性能非常差。

正解如果缓存行已经是 E 或 M 状态，当前核心是唯一持有者，写命中根本不需要广播。只有从 S 或 I 状态写入时才需要失效或取行。再加上写缓冲器能吸收总线等待时间，实际写路径并没有想象中那么慢。

为何常见：只看状态转换图里“S→M 需要失效”这一条分支，忽略了 E→M 和 M→M 的快速路径。

误区既然 MESI 保证每个核心读到最新数据，那么多线程程序只要用了 MESI 就不会有数据竞争。

正解MESI 只保证同一缓存行在硬件层面的值传递，不保证读-改-写操作的原子性，也不保证跨地址的全局顺序。两个线程同时给变量加 1，即使缓存永远一致，最后也可能只加了一次。锁、原子指令和内存屏障仍然不可替代。

为何常见：大家把硬件一致性和软件同步视为同一件事，其实前者是“数据不会传错”，后者是“操作不会乱序交错”。

面试题

Q1. MESI 中，一个核心对处于 S 状态的缓存行执行写操作，最合适的描述是？

单选题 · easy

  • A.直接修改，无需跟其他核沟通
  • B.先广播失效，让其他核置 I，再改为 M← 正确答案
  • C.先写回主存，再修改
  • D.等待其他核心同步成功后再修改

答案：B。S 状态意味着多个核心都有干净副本，当前核心不能只改自己的，否则其他核心会读到旧值。MESI 采用写失效策略：先广播失效，把别人的 S 打成 I，再将自己的行置为 M。这就像在群里先喊“旧版作废”再动手改文件。

Q2. 哪个状态表示“只有当前核心持有缓存行，且数据与主存一致”？

单选题 · easy

  • A.M
  • B.E← 正确答案
  • C.S
  • D.I

答案：B。M 是修改过的独占脏数据；E 是唯一且干净的副本；S 是干净但多份；I 是无效。E 就像是员工桌上唯一一份和公共文件柜一致的复印件，后续写它时不需要广播失效，直接升级为 M。

Q3. 总线嗅探（Bus Snooping）指的是？

单选题 · easy

  • A.每个核心监听总线请求并更新自身缓存状态← 正确答案
  • B.主存定期扫描所有缓存
  • C.操作系统轮询缓存
  • D.编译器分析缓存

答案：A。总线嗅探是硬件层面的机制：每个核心的缓存控制器持续监听共享总线上的请求，一旦发现与自己的缓存行相关，就切换状态或提供数据。它不依赖操作系统、编译器或主存主动扫描。

Q4. 在 MESI 中，某个核心的 M 状态缓存行被远程核心的读请求命中的，当前状态会如何变化？

单选题 · mid

  • A.M → I
  • B.M → E
  • C.M → S← 正确答案
  • D.M 保持不变

答案：C。M 表示本地持有最新的脏数据，远程核心要读这行时，本地必须把数据放到总线上供对方获取。因为双方现在都持有这行数据，本地不再是唯一持有者，所以状态降为 S。这就是“共享一份最新版本”的语义。

Q5. 写失效（Write Invalidate）相比写更新（Write Update）的主要优势是？

单选题 · mid

  • A.对同一缓存行连续多次写时，总线流量更小← 正确答案
  • B.不需要总线消息
  • C.不会产生缓存缺失
  • D.很容易实现原子性

答案：A。写更新协议每次写都要广播完整数据，而写失效只在第一次需要广播失效或取行。之后因为缓存行已经变成 M，后续多次写都不再需要总线事务，所以总线流量大幅减少。写失效仍然需要总线消息，也不能保证原子性。

Q6. 伪共享（False Sharing）的本质是？

单选题 · mid

  • A.两个核心共享同一个变量导致竞争
  • B.两个核心访问不同变量但位于同一缓存行，引发频繁失效← 正确答案
  • C.主存数据被缓存覆盖
  • D.缓存行大小太大

答案：B。伪共享的核心特征是：逻辑上没有共享变量，但两个变量被分配到同一条 64 字节缓存行。MESI 以缓存行为粒度维护一致性，任一个核写其中一个变量，另一个核的整行都要失效，因此产生大量不必要的广播和缺失。真实共享变量导致的是数据竞争，不是伪共享。

Q7. 除了缓存一致性，多核 CPU 还可能因写缓冲器出现什么问题？

单选题 · mid

  • A.其他核心可能暂时看不到最近写入← 正确答案
  • B.缓存行直接丢失
  • C.主存容量减少
  • D.所有写操作变慢

答案：A。写缓冲器让写操作先登记在缓冲区，CPU 不用等广播确认就能继续执行。但缓冲区里的写何时对其他核心可见是不确定的，于是其他核心可能暂时读到旧值，造成乱序感。这也是内存屏障指令存在的意义。

Q8. MESI 协议中，缓存行从 I 变为 E 而不是 S 的条件是？

单选题 · hard

  • A.总线读请求被某个缓存响应
  • B.总线读请求没有其他核心持有该行的有效副本← 正确答案
  • C.本地写请求不需要失效
  • D.主存返回数据失败

答案：B。I 状态的缓存行读缺失后，核心会向总线发出读请求。如果总线上没有其他核心拥有同一行的有效副本，说明当前核心是唯一持有者，可以进入 E；如果其他核心也有副本，就必须进入 S。E 是“唯一干净副本”的专属状态。

Q9. MESI 中 Modified 状态满足哪些性质？

多选题 · mid

  • A.当前缓存行与主存一致
  • B.当前核心可以直接写而不产生总线事务← 正确答案
  • C.可能有其他核心持有同一行的共享副本
  • D.数据最终需要写回主存← 正确答案

答案：BD。M 表示当前核心已经修改过缓存行，和主存不一致，因此 A 正确？不，A 错误。M 状态强调独占，所以不会有其他核心持有有效副本，C 错误。因为独占，写命中不需要总线事务，B 正确；因为被修改且独占，被替换时必须写回主存，D 正确。

Q10. 关于 MESI 及协议变体，正确的表述有？

多选题 · hard

  • A.MESI 采用写失效策略来维护一致性← 正确答案
  • B.MOESI 增加 Owned 状态，允许脏数据在多个缓存间共享← 正确答案
  • C.MESIF 用 Forward 状态避免多个缓存同时响应同一次读请求← 正确答案
  • D.MESI 能替代锁和原子操作保证程序逻辑安全

答案：ABC。MESI 的核心是写失效广播，A 正确。MOESI 的 O（Owned）状态允许缓存行既是脏的又可以被多个核共享，减少写回主存，B 正确。MESIF 的 F（Forward）状态指定唯一转发者，避免总线多份响应抢答，C 正确。但 MESI 只解决硬件缓存一致性，不保证原子性和跨地址排序，D 错误。