并发程序的隐形杀手：深入浅出 CPU 伪共享与性能优化

一、一个诡异的性能瓶颈

在性能调优中，我们经常遇到这样的场景：代码逻辑极其简单，线程间几乎无数据竞争，锁的使用也降到了最低，但程序的吞吐量就是无法随 CPU 核心数线性增长。例如下面这段用两个线程分别累加两个独立变量的 Java 代码：

两个线程各自修改 `Counter` 对象中**不同的字段** `x` 和 `y`，理论上没有共享数据，性能应当接近单线程的两倍。但在实际测试中（尤其是多核服务器），你会发现运行时间比预期慢得多。如果进一步使用性能分析工具观察，会发现大量时间消耗在 CPU 的缓存一致性消息上，而非计算本身。

这便是伪共享（False Sharing）在作祟。

二、理解 CPU 缓存的基本单位——缓存行

现代 CPU 为了提高数据访问速度，在主存与寄存器之间设计了多级高速缓存（L1、L2、L3）。数据在内存与缓存之间并非按字节传输，而是以固定大小的**缓存行（Cache Line）**为单位进行加载和失效，主流 x86 架构的缓存行大小通常为 **64 字节**。

当 CPU 核心 A 读取变量 `x` 时，它会把包含 `x` 地址在内的整块 64 字节数据加载到自己的 L1/L2 缓存中。如果变量 `y` 在内存中紧挨着 `x`，它们就极有可能落入**同一个缓存行**。

三、缓存一致性协议（MESI）的代价

多核环境下，每个核心都有自己的私有缓存。为了维护数据的一致性，CPU 遵循诸如 **MESI**（Modified, Exclusive, Shared, Invalid）这样的缓存一致性协议。其核心规则是：**当某个核心修改了其缓存行中的数据，其他核心中对应的同一缓存行副本必须被标记为失效（Invalid）**。

回到上文的例子：
1. 核心 A 修改 `c.x`，它必须先拥有该缓存行的独占权（Modified 状态）