3. 缓存一致性协议：MESI协议详解，False Sharing问题

3.1 为什么需要缓存一致性？

多核CPU时代，每个核心都有自己的L1/L2缓存。你想想看，如果两个核心同时读写同一个内存地址，会发生什么？

我刚开始接触这个问题时，觉得很简单——加锁不就完了？后来在项目中调试一个诡异的性能抖动，才发现事情远没那么简单。核心A改了数据，核心B还在用自己缓存里的旧值，程序就乱套了。

这就是缓存一致性问题。说白了，就是要保证所有核心对同一内存地址的认知是一致的。

3.2 MESI协议：四个状态的博弈

MESI协议是目前最经典的缓存一致性协议。它给每个缓存行定义了四种状态：

状态	全称	含义	该缓存行是否有效	其他核心是否有副本
M	Modified	已修改，数据只在本核心缓存中	是	否
E	Exclusive	独占，数据只在本核心缓存中	是	否
S	Shared	共享，多个核心都有该数据副本	是	是
I	Invalid	无效，该缓存行不可用	否	—

嗯，这里要注意：M和E状态都表示数据是「独占」的，区别在于M状态的数据已经被修改过，而E状态的数据和内存一致。

3.3 状态转换：一个读写操作的完整旅程

我习惯用「读」和「写」两个操作来理解状态转换。举个例子：

• 本地读命中：如果缓存行是M/E/S状态，直接读，状态不变。
• 本地读缺失：如果缓存行是I状态，需要从内存或其他核心获取数据。如果其他核心有副本，变成S状态；否则变成E状态。
• 本地写命中：如果缓存行是E/M状态，直接写，变成M状态。如果是S状态，需要先发送Invalidate消息让其他核心失效，再写，变成M状态。
• 本地写缺失：先读数据，再写，最终变成M状态。

我在项目中遇到过一个问题：一个看似简单的计数器累加，在多核下性能惨不忍睹。后来发现就是频繁的MESI状态转换导致的。

3.4 False Sharing：看不见的性能杀手

False Sharing（伪共享）是我在性能优化中遇到最多的坑之一。它是什么？

假设两个线程分别操作两个不同的变量，但这两个变量恰好在同一个缓存行里。线程A修改变量a，导致缓存行变成M状态，线程B的缓存行被Invalidate。线程B要读变量b时，发现缓存行失效，只能重新从内存加载。

明明操作的是不同变量，却因为共享同一个缓存行而互相拖累。这就是「伪共享」。

3.5 如何检测和避免False Sharing？

检测方法：

• 使用perf工具观察cache-miss事件
• 检查热点数据的内存地址是否对齐到缓存行边界
• 观察CPU性能计数器中的「共享缓存行冲突」指标

避免方法：

• 缓存行填充（Padding）：在变量前后填充无意义的字节，确保每个变量独占一个缓存行
• 数据对齐：将热点变量按64字节对齐
• 线程本地存储：尽量使用线程局部变量，减少共享

3.6 知识体系图：MESI与False Sharing的关系

3.7 实战：一个False Sharing的代码示例

// 有False Sharing问题的代码
struct Data {
    int a;  // 线程1操作
    int b;  // 线程2操作
};

// 修复后的代码：使用缓存行填充
struct DataFixed {
    int a;
    char padding[60];  // 填充到64字节
    int b;
};

你想想看，上面这个例子中，a和b在同一个缓存行里。线程1频繁写a，线程2频繁读b。每次写a都会让线程2的缓存行失效，导致性能急剧下降。

修复后，a和b分别在不同的缓存行中，互不干扰。我在实际项目中用这种方法优化过一个消息队列，吞吐量提升了3倍。

3.8 总结

MESI协议是理解多核缓存行为的基石。False Sharing则是实际开发中最容易踩的坑之一。记住三点：

• 缓存行是64字节对齐的
• 不同核心操作同一缓存行中的不同变量，就是False Sharing
• 用填充或对齐来隔离热点数据

嗯，这些知识看起来简单，但真正用好需要大量实践。我每次做性能优化时，都会先检查缓存行为，往往能发现意想不到的问题。

---

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