内存层级：CPU缓存对数据读写延迟的影响

说到性能优化，有个东西绕不开——CPU缓存。我刚开始做高性能系统时，总觉得缓存是硬件工程师的事，跟我们写代码的没啥关系。直到有一次，一个看起来简单的数据写入操作，死活跑不到预期速度，排查了三天，最后发现是缓存行对齐的问题。嗯，从那以后，我再也不敢忽视这个“小东西”了。

CPU缓存长什么样？

现代CPU一般有三层缓存：L1、L2、L3。你可以把它们想象成三个不同大小的“临时仓库”。

缓存层级	典型大小	访问延迟	位置
L1	32KB - 64KB	约1ns（3-4个CPU周期）	每个核心独享
L2	256KB - 512KB	约3-5ns（10-15个周期）	每个核心独享
L3	8MB - 32MB	约10-15ns（30-50个周期）	所有核心共享

你想想看，从L1读数据只要1纳秒，从主存读要100纳秒。差了整整两个数量级。说白了，你的程序慢不慢，很多时候就取决于数据在不在缓存里。

缓存行：最小的传输单位

CPU不按字节从内存读数据，而是按“缓存行”来读。一个缓存行通常是64字节。这意味着，你哪怕只读一个int（4字节），CPU也会把相邻的60个字节一起拉进来。

这个设计本身是好的——利用空间局部性。但搞不好，就会踩坑。

伪共享：多线程性能的隐形杀手

我在项目中遇到过最典型的性能问题，就是伪共享。当时一个多线程程序，线程数从4加到8，性能反而下降了。查了半天，发现两个线程频繁访问的两个变量，恰好落在同一个缓存行里。

为什么会这样？

假设线程A在核心0上运行，线程B在核心1上运行。它们各自修改变量x和y。如果x和y在同一个缓存行里，那么：

1. 核心0修改x，缓存行变成“脏”的
2. 核心1要修改y，发现缓存行失效，得重新从内存加载
3. 核心1修改y，核心0的缓存行又失效了
4. 两个核心来回“抢”这个缓存行，性能直线下降

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

如何解决伪共享？

解决方案其实很简单：让不同线程访问的变量落在不同的缓存行里。常用的方法有两种。

方法一：缓存行填充

在C++中，可以在变量后面加填充字节，确保每个变量独占一个缓存行。

// 伪共享版本
struct Data {
    int x;  // 线程A操作
    int y;  // 线程B操作
};

// 缓存行对齐版本
struct alignas(64) Data {
    int x;
    char padding[60];  // 填充到64字节
    int y;
    char padding2[60]; // 填充到64字节
};

注意，C++11之后可以用alignas(64)直接指定对齐。我个人习惯用这个，代码更干净。

方法二：使用thread_local

如果每个线程只操作自己的数据，用thread_local是最干净的方案。

thread_local int thread_local_data;

void worker() {
    // 每个线程有自己的副本，不存在伪共享
    thread_local_data++;
}

缓存行对齐的实战技巧

除了伪共享，缓存行对齐本身也能提升性能。我举个例子：

// 未对齐：可能跨两个缓存行
struct BadAligned {
    char a;
    int b;  // 可能跨缓存行边界
};

// 对齐：保证int在同一个缓存行内
struct alignas(64) GoodAligned {
    char a;
    char padding[3];
    int b;
};

未对齐的变量，CPU可能需要两次内存访问才能读完。对齐后，一次搞定。在微秒级写入的场景下，这个差异非常明显。

知识体系总览

下面这张图，把缓存层级、延迟差异、伪共享问题串起来了。你可以对照着理解。

总结一下

缓存这个东西，说白了就是“距离产生美”。离CPU越近，速度越快。但多线程环境下，缓存行共享反而成了性能瓶颈。

• L1/L2：每个核心独享，延迟最低
• L3：所有核心共享，延迟稍高
• 缓存行：64字节，是数据传输的最小单位
• 伪共享：多线程操作同一缓存行中的不同变量，导致缓存失效
• 解决方案：缓存行填充、thread_local、alignas

嗯，这些概念看起来简单，但真正用起来，得结合你的实际场景。我建议你在写多线程代码时，先想想数据会不会被多个核心同时访问。如果会，那就花点心思做缓存行对齐。这点投入，回报率极高。