一、缓存友好编程：从CPU缓存说起

各位同学好，我是你们的老朋友。今天我们来聊聊缓存友好编程。说实话，这个话题我每次讲都特别有感触——因为我在职业生涯早期，就吃过不懂缓存的亏。

先问大家一个问题：你写代码时，有没有遇到过这种情况——明明算法复杂度很低，但程序跑起来就是慢？

嗯，很可能问题出在CPU缓存上。

1.1 CPU缓存层级：为什么需要三级缓存？

现代CPU的缓存结构，说白了就是一个金字塔。从上到下，容量越来越大，速度越来越慢。

你想想看，L1缓存比主存快了将近100倍。这意味着什么？意味着如果你的数据在L1里，程序跑得飞起；如果数据在主存里，CPU就得干等着。

我个人习惯把缓存层级想象成一个「快递站」：L1是家门口的快递柜，L2是小区驿站，L3是区域分拣中心，主存是远在郊区的仓库。你当然希望快递就在家门口，对吧？

1.2 缓存行与伪共享：一个让我踩过坑的地方

缓存行（Cache Line）是CPU缓存的最小单位，通常是64字节。也就是说，CPU从主存加载数据时，一次加载64字节。

这里有个坑——伪共享（False Sharing）。

我在项目中遇到过这样一个场景：两个线程各自修改不同的变量，但这两个变量恰好落在同一个缓存行里。结果呢？两个线程互相「踢」对方的缓存行，性能直接腰斩。

// 两个线程分别修改 a 和 b
struct Data {
    int a;  // 线程1修改
    int b;  // 线程2修改
};  // a和b很可能在同一个缓存行里

// 使用 alignas 强制对齐到缓存行边界
struct alignas(64) Data {
    int a;  // 线程1修改
    char padding[60];  // 填充到64字节
    int b;  // 线程2修改
};

我曾经在一个高并发服务里排查性能问题，发现两个核心的计数器互相拖累。加上缓存行对齐后，吞吐量提升了30%。嗯，这个教训很深刻。

1.3 数据局部性优化：让数据「挨着放」

数据局部性分为两种：

• 时间局部性：刚访问过的数据，很可能再次被访问
• 空间局部性：刚访问过的数据附近的数据，很可能被访问

说白了，就是让CPU觉得「嗯，这哥们儿访问数据挺有规律的，我提前把附近的数据都加载进来吧」。

来看一个经典的反例：

// 坏写法：按列遍历，跳跃访问
for (int j = 0; j < N; ++j) {
    for (int i = 0; i < M; ++i) {
        sum += matrix[i][j];  // 每次访问都跳到下一行
    }
}

// 好写法：按行遍历，连续访问
for (int i = 0; i < M; ++i) {
    for (int j = 0; j < N; ++j) {
        sum += matrix[i][j];  // 连续内存访问
    }
}

你猜猜看，这两种写法性能差多少？我在一个1024x1024的矩阵上测试过，按行遍历比按列遍历快了将近10倍。为什么？因为按行遍历充分利用了缓存行的空间局部性。

1.4 分支预测优化：别让CPU「猜错」

分支预测是CPU的一个「猜谜游戏」。它根据历史记录，猜测if语句会走哪条路。猜对了，流水线顺畅；猜错了，流水线清空，性能损失惨重。

我记得有一次优化一个排序算法，发现性能瓶颈居然在分支预测上。数据是随机分布的，分支预测成功率只有50%，CPU一半的时间都在「猜错-清空-重来」。

// 分支预测友好写法
// 假设我们处理的数据大部分是正数
if (__builtin_expect(value > 0, 1)) {
    // 处理正数
} else {
    // 处理非正数
}

这里有个小技巧：如果你知道数据分布，可以用__builtin_expect给编译器提示。但别滥用，我见过有人每个if都加，反而让代码变得难以维护。

知识体系总览

下面这张图，是我自己总结的缓存友好编程知识体系。你可以把它当作一个「检查清单」：

总结一下

缓存友好编程，说白了就是「让CPU少等一会儿」。我总结了几个核心要点：

1. 理解缓存层级：知道数据在哪儿，才能决定怎么访问
2. 避免伪共享：多线程场景下，用缓存行对齐保护你的性能
3. 利用局部性：连续访问、行优先遍历，让缓存行发挥最大价值
4. 优化分支：让CPU的「猜谜游戏」胜率更高

最后说一句：这些优化技巧，不要一开始就用。先写正确的代码，然后用性能分析工具（比如perf）找到热点，再针对性地优化。我曾经见过有人为了「缓存友好」把代码写得乱七八糟，结果性能反而更差。

好了，今天就聊到这儿。记住：让数据靠近CPU，让访问变得规律，让分支变得可预测——这就是缓存友好编程的精髓。