写并发程序的人多多少少都遇到过一个怪现象:两个线程在逻辑上明明操作的是不同变量,程序却慢得跟加了全局锁似的;或者更邪门,不加任何同步手段,一个线程刚改完值,另一个线程读到的结果却时新时旧。这些问题表面看是编译器优化或线程调度的问题,可往深了追,真正的根子往往都落在 CPU 缓存一致性上。而 MESI 协议,就是维护这块一致性的核心机制,也是现代多核 CPU 上几乎所有缓存方案的“母版”。
这篇文章我会按“为什么有这个问题 → 协议内部如何运转 → 在物理机上怎么观察和验证 → 教科书协议与实际 CPU 实现的差异”这条线来拆。不写教科书式的概念复述,重点放在状态转换的逻辑、缓存行上的总线交互,以及如何用 perf、伪共享实验把这些看不见的行为变成能测量的数据。适合刚接触 MESI 的开发者,也适合那些已经能背下四种状态、但想知道“协议到底怎么在线上跑起来”的进阶读者。
1. 为什么需要 MESI:多核 CPU 的交通规则
1.1 从缓存说起:为什么要引入多级缓存
要理解 MESI,得先理解为什么 CPU 需要缓存。CPU 的运算速度与内存访问延迟之间隔着几十年的差距。现代 CPU 一纳秒能执行好几条指令,而访问主内存的延迟动辄七八十纳秒,甚至上百纳秒。如果每次取数都直接访问内存,CPU 大部分时间都在等待,于是设计者把一小块更快、更接近核心的存储放在 CPU 和内存之间——这就是 L1、L2、L3 缓存。
L1 缓存通常跟核心绑定,延迟约 1 纳秒左右;L3 则被多个核心共享,延迟大约 30-40 纳秒。从软件角度看,这些缓存是“透明的”:你只管读写变量,CPU 硬件负责把数据从内存搬到缓存,再把修改后的数据写回内存。但在多核场景下,透明就不再是好事了,因为每个核心都有一份自己的缓存,同一地址的数据可能同时存在于多个核心的 L1 里。
1.2 一个最简单的冲突场景
假设核心 0 和核心 1 同时都在运行线程,两个线程需要共享一个变量 x。数据从内存被读入缓存后,核心 0 的 L1 里面有一份副本,核心 1 的 L1 里也有一份副本。此时线程 A 把 x 改成了 1,线程 B 读到的却是旧值 0。也就是说,两个核心对同一地址的视图出现了分歧。
这还只是最直观的问题。更麻烦的是,不同缓存副本的更新顺序必须对所有核心是一致的,否则程序难以正确协同。比如线程 A 写标志位 ready = true,线程 B 依赖这个标志位判断数据是否就绪。如果 B 读到的 ready 是新的,但 data 还是旧的,那整个并发协作的逻辑就全乱了。
1.3 一致性的两个基本要求:写传播与写串行化
所有缓存一致性协议,本质上都要满足两个要求:
- 写传播(Write Propagation):任何一个核心对缓存行的修改,必须能够被其他核心看到。也就是说,你的写入要在合理时间内传达给所有可能读到该数据的核心。
- 写串行化(Write Serialization):所有核心对同一地址的写操作,看到的顺序必须一致。核心 A 先写值 1,核心 B 后写值 2,那么任何读操作要么先看到 1 再看到 2,要么最终只看到 2,不能出现“有人看到 2 后又看到 1”这种时间倒流。
规定这两点是理解 MESI 的关键。我见过不少文章把 MESI 描述得玄乎,动不动就说“缓存同步”,好像缓存之间会像路由器一样互相交换数据。实际上 MESI 不过是一套分布式状态机的规则,每条规则都在解决上面两个问题中的某一个。
1.4 为什么不直接用一把“大锁”
有读者可能会问:既然怕多核数据不一致,那干脆把缓存访问全局加锁,或者所有读写都直接走内存不就行了?确实可以,但这会丢掉缓存存在的意义。
如果所有读写都直达内存,缓存命中率对性能优化的功劳就归零了,CPU 的流水线会频繁被内存延迟卡住。如果给缓存访问上大锁,那么两个核心即使访问不同的变量,也会被强制串行化,相当于把多核并行降级成单核。所以 MESI 的设计目标其实很克制:只在同一缓存行的数据被多个核心共享时,才付出跨核心通信的代价;如果数据是某个核心独占的,就让它独享,不打扰任何其他核心。
这个设计哲学贯穿整个协议——MESI 的性能上限来自于 E(Exclusive)状态和 M(Modified)状态带来的“无总线通信”快路径。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. MESI 的四种状态与总线上的“对话”方式
2.1 四种状态的真实含义
MESI 这四个字母分别代表缓存行的四种状态:
| 状态 | 含义 | 数据是否有效 | 与内存是否一致 | 其他核心是否可能有副本 |
|---|---|---|---|---|
| M(Modified) | 本核心修改过,尚未写回内存 | 有效 | 不一致 | 不可能有 |
| E(Exclusive) | 本核心独占,未修改 | 有效 | 一致 | 不可能有 |
| S(Shared) | 可能多个核心共享 | 有效 | 一致 | 可能有 |
| I(Invalid) | 无效,不能直接使用 | 无效 | 不关心 | 不关心 |
注意 E 和 S 的核心差别不在数据新旧,而在于“是否允许其他核心持有副本”。一个缓存行处于 E 状态时,本核心可以放心写它,因为全系统只有自己手里有这份数据,改完只需要标记为 M,连通知都不需要发。而 S 状态则意味着可能有兄弟核心也持有同样的副本,想写就得先“宣告主权”让其他副本失效。
从工程角度看,E 状态是一个巨大的优化,它让“没有共享的写”完全走本地快路径。现代编译器和运行时无法在编译期判断数据将来是否会被共享,所以 CPU 只能在运行时动态维护这个状态。这也是 MESI 比简单的“读共享/写独占”两级协议更高效的原因。
2.2 总线上的四种请求:BusRd、BusRdX、BusUpgr、Flush
在经典的 MESI 实现中,核心之间通过总线进行通信。总线上传递的“请求”主要有四种。理解这些请求,比死记状态转换表更容易抓住协议的脉络:
- BusRd(总线读):一个核心想读某个缓存行,但本地没有有效副本。它向总线广播“谁有这个地址的数据?”。如果有其他缓存持有 S 或 E 状态,它可以提供数据;否则由内存提供。
- BusRdX(总线读独占):一个核心想写某个缓存行,但本地没有有效副本。它向总线广播“我要独占这个地址,所有持有该数据的副本立即失效”。这个请求既负责取数据,又负责让旧副本全部作废。
- BusUpgr(总线升级):一个核心本地已经有 S 状态的数据,现在想写它。此时不需要重新读数据,只需要广播“把这个地址的其他副本全部置为 I”。这个请求比 BusRdX 更省带宽,因为它不要求内存或兄弟缓存再发一份数据给你。
- Flush(刷新):当一个核心发现别人的总线请求命中了本地状态为 M(或 E)的缓存行时,它需要把本地数据“吐”出来。Flush 会把修改过的数据写回内存,或者直接转发给请求核心。
这四类请求并不全是“完整总线事务”的全部细节,但已经足够解释状态转换中的大多数关键行为。面试里常问的“写一个共享变量要几步”,答案的实质就是:根据当前状态决定发 BusRdX 还是 BusUpgr。
2.3 状态转换全景:缓存行的一生
下面用一个大表展示结合总线请求的状态迁移。横向是“当前状态”,纵向是“事件”,格子里是“下一个状态 + 是否发送总线请求”。
| 事件 | I | S | E | M |
|---|---|---|---|---|
| 本地读命中 | 不可能 | S | E | M |
| 本地写命中 | 不可能 | M,发 BusUpgr | M,无需请求 | M |
| 本地读未命中(其他核心持有该行) | S,发 BusRd | 不适用 | 不适用 | 不适用 |
| 本地读未命中(只有内存持有) | E,发 BusRd | 不适用 | 不适用 | 不适用 |
| 本地写未命中 | M,发 BusRdX | 不适用 | 不适用 | 不适用 |
| 观察到 BusRd 命中本行 | 保持 I | S | S | 回写并变为 S |
| 观察到 BusRdX 命中本行 | 保持 I | I | I | 回写并变为 I |
| 观察到 BusUpgr 命中本行 | 保持 I | I | 保持 E(一般不会发生) | 保持 M |
这张表实际上是很多架构教材里那张状态图的文字版。建议你以这段生命周期来记忆:一个缓存行最初以 E 状态从内存被加载;第一次被其他核心读取就降级为 S;写入时若处于 S,需要发送 BusUpgr 抢到独占权变成 M;若处于 M 时被其他核心读请求命中,就把数据让出去变成 S;被写请求命中则直接作废为 I。
2.4 一个容易忽略的细节:什么时候“只靠内存提供数据”
很多初学者以为缓存行缺失后永远走内存。实际上在现代多级缓存架构中,L1 缺失后往往有一个 L2/L3 的共享缓存兜底,多个核心的 L1 之间也会有直接转发路径。MESI 协议原本并不规定“谁负责最终提供数据”的物理实现,它只定义了状态和请求语义。所以当你读到“BusRdX 会从内存读”这类描述时,要清楚那是最简化的单总线模型;真实 CPU 中,数据可能由兄弟核心的 L1 提供,也可能由 L3 提供,还可能是从多插槽场景下的远端内存提供。
3. 缓存行粒度与状态机背后的物理现实
3.1 为什么粒度是“缓存行”而不是“变量”
MESI 状态不是按变量维护的,而是按缓存行(cache line)维护的。多数 x86 架构的缓存行大小是 64 字节,ARM 通常是 64 字节,一些老平台可能是 32 字节。一个缓存行里会包含多个变量,所以当你修改其中任何一个变量时,整个缓存行都会被打上 M 标记,其他核心读取同一行中的其他变量时也会被牵连。
这就是所谓的“伪共享(False Sharing)”的来源:两个线程分别在改两个毫无关系的变量,但因为这两个变量落在同一个缓存行里,MESI 不得不让整个缓存行在核心之间来回“搬家”。在协议看来,它们共享了同一份数据;在程序逻辑看来,这是彻头彻尾的误会。
3.2 一次读未命中的完整链路
我拿一个最典型的场景解释这条链路:核心 0 执行 int x = data[0],本地 L1 没有 data[0] 所在缓存行。
- 核心 0 向总线发出 BusRd。
- 核心 1 监听总线,发现自己的 L1 中恰好有该地址的缓存行,且状态为 M。
- 核心 1 中断自己的访问,把缓存行数据通过总线发送给核心 0,同时该行状态从 M 变为 S(数据已共享给他人,内存也尚未更新,但以 S 状态存在是因为核心 0 现在也有一份)。
- 核心 0 收到数据,将该行加载到 L1,状态设为 S。
- 内存控制器不会收到写请求,因为数据不是从内存读的。但这通常不影响最终一致性:后续任意一个核心再写该行时,会通过 BusUpgr/BusRdX 让所有 S 副本失效,届时 M 状态的核心负责回写。
这个过程中最“反直觉”的一点是:核心 1 明明只是在执行别的指令,却因为总线上的一声广播被拉入数据搬运的业务。这也是为什么高并发场景下“共享数据”会成为系统的隐形瓶颈。
3.3 一次写命中的完整链路
场景:核心 0 目前持有缓存行,状态为 S;它执行 data[0] = 1。
- 核心 0 发现本地状态是 S,不能默默修改,因为其他核心可能还有 S 副本。
- 核心 0 发出 BusUpgr。
- 其他持有该行 S 状态的核心嗅探到 BusUpgr,将本地状态置为 I。
- 核心 0 将状态从 S 改为 M,然后真正写入缓存行。
- 如果之后核心 1 再读这个地址,会触发 BusRd,核心 0 通过 Flush 把最新数据发出去,状态降为 S。
如果场景改成核心 0 的状态是 E,那么第 2、3 步都可以省略,直接写入并切换为 M。E 状态的威力在这里体现得淋漓尽致:独占写完全没有任何总线事务,性能等于对该缓存行做本地写。真实程序里很多数据是线程私有的,这种“无成本一致性”是 MESI 对常见工作负载的一种天然适配。
3.4 总线嗅探与多核缓存的“可见性”
MESI 要求每个核心的缓存控制器持续“嗅探”总线上的请求,即使这些请求与当前正在执行的指令无关。这种嗅探机制有一个显著代价:功耗高,而且总线带宽有限。现代 CPU 很少使用单一共享总线,而是采用环形总线、Mesh 网络等拓扑,但“所有缓存控制器都能感知一致性相关事件”这一点没变。
这里有一个非常容易误解的点:MESI 并不保证“一个核心写完立刻就能被另一个核心读到”。它在协议层面保证的是最终一致性——只要总线请求传播完成,数据就会收敛。至于“多久算完成”,取决于总线的物理传播时间与各缓存控制器的处理速度。真实 CPU 里这个窗口非常小,但并不是绝对的零,这也是后面要讲 store buffer 和内存屏障的重要原因。
4. 实战:如何在物理机上观测 MESI 的行为
4.1 用 perf 统计缓存失效
纸上谈兵再多,不如亲眼看到数据。Linux 下最常用的工具是 perf。先写一个简单的 C 程序,让它循环修改一个全局变量:
c复制#include <pthread.h>
#include <stdatomic.h>
#include <stdint.h>
#define LOOP_COUNT 100000000
volatile uint64_t counter = 0;
void* worker(void* arg) {
for (int i = 0; i < LOOP_COUNT; i++) {
counter++;
}
return NULL;
}
int main() {
pthread_t t1, t2;
pthread_create(&t1, NULL, worker, NULL);
pthread_create(&t2, NULL, worker, NULL);
pthread_join(t1, NULL);
pthread_join(t2, NULL);
return 0;
}
编译运行并统计缓存事件:
bash复制gcc -O2 -pthread test.c -o test
perf stat -e task-clock,cache-references,cache-misses,context-switches ./test
观察 cache-references 和 cache-misses 的数值。需要注意的是,perf 的事件解释在不同 CPU 上略有差异,但趋势很有参考价值:如果两个线程争抢同一个变量,cache-misses 会显著偏高。因为每次 counter++ 都会让缓存行在所有核心之间来回失效、重新加载。
如果机器支持更细粒度的性能计数器,可以进一步尝试:
bash复制perf stat -e l1d_cache_rd_miss,l1d_cache_wr_miss ./test
某些 ARM 平台上事件名不同,可以用 perf list 查看可用的事件名称。
4.2 伪共享实验:什么是“看不见的共享”
下面这个稍微复杂一点的实验,能让你直观地感受到 MESI 因为缓存行粒度而带来的额外开销。
考虑一个结构体,里面有两个 int64_t 字段:
c复制#include <pthread.h>
#include <stdint.h>
#include <stdio.h>
#define LOOP_COUNT 500000000
struct data {
volatile int64_t a;
volatile int64_t b;
} g_data;
void* write_a(void* arg) {
for (int i = 0; i < LOOP_COUNT; i++) {
g_data.a++;
}
return NULL;
}
void* write_b(void* arg) {
for (int i = 0; i < LOOP_COUNT; i++) {
g_data.b++;
}
return NULL;
}
两个线程一个只写 a,一个只写 b。按程序逻辑它们完全无共享,但 a 和 b 在同一个 64 字节缓存行里,MESI 认为它们是同一份数据。所以每次 a 被修改,b 所在缓存行也会在另一个核心上失效;写 b 同样会让 a 的缓存行失效。结果就是两个线程互相拖后腿。
编译运行对比单线程版本,你会发现多线程版本不仅没变快,反而可能比单线程还慢。这就是伪共享的典型症状。用 perf stat 对比时,伪共享版本会出现极高的 cache-misses 比例。
4.3 消除伪共享:让每个变量独占缓存行
改正方法非常直接:让 a 和 b 分别落在两个缓存行里。C11 里可以用 alignas:
c复制#include <stdalign.h>
struct data {
alignas(64) volatile int64_t a;
alignas(64) volatile int64_t b;
};
这样 a 从地址的 64 字节对齐位置开始,b 也起始于下一个对齐位置,两者不可能落在同一个缓存行。C++17 提供了更语义化的做法:
cpp复制#include <new>
struct data {
alignas(std::hardware_destructive_interference_size) std::atomic<int64_t> a;
alignas(std::hardware_destructive_interference_size) std::atomic<int64_t> b;
};
Java 中则可以借助 @sun.misc.Contended 注解(需要 -XX:-RestrictContended 或默认 JVM 参数下在 JDK 内部类才生效,应用类一般加上 -XX:-RestrictContended 才能用于用户代码),或者手动 padding 一个 64 字节数组。
改完之后再跑一次,你会发现两个线程的耗时明显下降,cache-misses 也大幅回落。这个例子充分说明:MESI 的一致性机制本身没问题,真正问题在于“数据布局是否与协议粒度对齐”。
4.4 实验里很容易踩的坑
跑这类实验有几点经验要提醒一下:
- 优化等级别用
-O0。-O0会把变量存在栈上,且频繁读写内存,实验结果容易被噪声干扰。用-O2才能看到真实场景。 - 线程要绑定核心。如果线程不够密集,操作系统可能会让它们来回切换,导致缓存命中率数据完全失真。用
taskset -c 0,1 ./test把两个线程分别绑到 0 号、1 号核心。 - 数据要足够热。循环次数太少,预热和内核调度的开销会淹没缓存失效的差异。上面例子里的量级通常够用。
- 不是所有平台都严格 64 字节。ARM 上可以用
sysctl -a | grep cache或读取/sys/devices/system/cpu/cpu0/cache/下的信息确认缓存行大小。
5. 教科书 MESI 与实际 CPU 实现之间的鸿沟
5.1 store buffer:MESI 在真实 CPU 上不够用了
如果我们严格在硬件上完全实现经典 MESI,会碰到一个性能问题:当核心需要写一个 S 状态的缓存行时,必须发送 BusUpgr 并等待其他核心确认失效后才能真正写入。在高速 CPU 流水线里,这个等待可能是几百个周期的停滞,对于写密集型的指令流来说完全不可接受。
于是真实 CPU 引入了 store buffer:写操作先进入一个 FIFO 队列,CPU 不等总线确认就继续执行后续指令,由 store buffer 负责后续的总线通信和数据落盘。这极大提升了写性能,但也引入了一个新问题:store buffer 不总是透明的。一个核心改了变量,另一个核心可能读不到最新值,因为写入还滞留在 store buffer 里。
这就是为什么我们在并发编程中需要 sfence、mfence、atomic_thread_fence 这些内存屏障。它们本质上是在告诉 CPU:执行到这里,必须先把 store buffer 里的相关写入刷出去,等待一致性协议真正生效。MESI 保证的是“并发写入最终一致”,而内存屏障保证的是“关键时刻的顺序一致性”。
5.2 invalidate queue:又从“读”那边拖后腿
store buffer 解决了写等待问题,却没有解决“读请求需要等待失效确认”带来的延迟。当缓存控制器收到 BusUpgr/BusRdX 时,它需要在总线上广播确认。如果每个核心都忙得不可开交,确认消息的传播也会成为瓶颈。
于是很多实现又引入了 invalidate queue:收到失效请求时不是立刻执行,而是塞进一个队列里,稍后再处理。这进一步加大了窗口,让“旧数据”的可见时间变长。所以进入多核时代后,我们不仅需要关注 MESI 本身,还需要理解缓存一致性协议与内存屏障、原子指令之间的关系。这也是为什么理解 MESI 的人再看 Java 的 volatile、C++ 的 std::atomic,会有种豁然开朗的感觉——它们实际上是在跟“被 store buffer 和 invalidate queue 削弱过的 MESI”打交道。
5.3 真实 CPU 的衍生协议:MESIF 与 MOESI
经典的 MESI 是理论基础,但实际厂商几乎不会原样照搬:
- Intel 的 MESIF:在 S 状态上增加一个 F(Forward)状态。同一缓存行在多个核心中处于 S 状态时,只有 F 状态的核心被允许响应其他核心的读请求并转发数据。这样避免了多核心同时响应同一条 BusRd 带来的总线竞争,在多路(多插槽)服务器上尤其重要。
- AMD 的 MOESI:增加 O(Owned)状态。O 状态允许缓存行同时处于“被修改”和“被共享”的状态:数据可能比其他缓存新,但内存里还没有更新。由持有 O 状态的核心负责向其他核心转发数据,而不急于写回内存。这减少了不必要的内存写流量。
实际工作中,我们很少需要区分这些变体,但你如果做性能排查,看到某个多路服务器上写回行为异常,大概率是 MESIF/F 状态带来的转发差异,而不是内存坏了。
5.4 从 MESI 到内存模型:编程语言里为何还要那一层
MESI、store buffer、invalidate queue 这些是在硬件层面保证“某个地址的数据不会彻底乱套”。但程序语言要表达的是更复杂的可见性语义——比如:我写了一个普通的 int,又写了一个 bool,另一个线程先看到 bool 为 true,能不能保证 int 也已经被看到?
这个问题仅靠 MESI 无法给出答案,因为硬件只保证协议意义上的缓存一致性,并不保证程序指令的顺序一致。于是各语言定义了内存模型:Java 内存模型规定了 volatile 的偏序关系,C++ 内存模型定义了 std::atomic 的 memory_order。编译器负责生成合适的 CPU 指令和内存屏障,让程序逻辑在“弱兮兮的 MESI+”之上达到符合预期的效果。
这也解释了另一个常见误区:以为只要 CPU 开启了 MESI,写基本类型变量、读基本类型变量就是完全原子的、顺序的。实际上原子性还需要总线锁或原子指令(如 x86 的 lock xchg)配合,而顺序性需要内存屏障配合。MESI 解决了“缓存行”层面的可见性,但没解决“指令流序”的问题。
5.5 排查多核性能问题时的一点建议
如果你在项目里遇到了多核程序“莫名慢”的情况,除了背 MESI 状态表,我建议按以下顺序查:
- 确认数据是否被真正共享。用
perf看cache-misses,先排除伪共享。 - 确认是不是有同步原语造成的 cache-line 抖动。锁、原子操作、
fetch_add这一类都会引发总线流量。 - 如果是跨 NUMA 节点共享数据,MESI 的问题会被放大成跨内存控制器访问,开销可能比缓存失效还大。
- 如果代码里大量使用内存屏障,考虑能不能减少共享写的频率,而不是盲目加
volatile。
多核性能问题的根源往往不是单个机制,而是数据布局、访问频率、同步策略三者纠缠。MESI 提供了观察这一切的底层视角,但最终的优化还是要回到“少共享、少写、少等待”这一朴素原则。
在我实际排查过的项目里,有一半以上的“多线程反而变慢”案例都能归到伪共享或者锁竞争导致的缓存行抖动,而不是算法复杂度问题。学会用 MESI 的视角去审视代码,再配合 perf 的数据验证,定位这类问题的速度会比闷头看代码快得多。如果你刚接触这块,建议先动手跑一遍第 4 节的伪共享实验,把状态转换和总线交互真实地“看”一遍,比死记硬背十遍状态图都管用。
