17、缓存友好代码：数据局部性、结构体布局优化、预取指令

大家好，我是你们的老朋友。今天我们来聊聊缓存友好代码。这个话题，说白了就是怎么让你的程序跑得更快，而且是那种“不花钱”的优化。

我记得刚入行那会儿，写了个排序算法，自认为效率很高。结果一跑，慢得像蜗牛。我百思不得其解，后来一位老前辈看了一眼，说：“你小子，缓存命中率太低了。” 从那以后，我才真正开始重视缓存这回事。

为什么缓存这么重要？

你想想看，CPU 主频已经快到 GHz 级别了，但内存的访问速度呢？还停留在纳秒级。这中间的差距，就像你开法拉利去取快递，结果快递站在胡同里，车开不进去，你得下车走。缓存，就是那个“胡同口的代步车”。

CPU 访问 L1 缓存大概需要 1 纳秒，访问主存却要 100 纳秒。差了整整两个数量级！所以，让数据尽量待在缓存里，就是性能优化的核心。

数据局部性：你的代码是“顺序”还是“跳跃”？

先看个例子。假设我们要遍历一个二维数组：

// 缓存友好版本：按行遍历
int sum_row_major(int matrix[1024][1024]) {
    int sum = 0;
    for (int i = 0; i < 1024; i++) {
        for (int j = 0; j < 1024; j++) {
            sum += matrix[i][j];  // 内存连续访问
        }
    }
    return sum;
}

// 缓存不友好版本：按列遍历
int sum_col_major(int matrix[1024][1024]) {
    int sum = 0;
    for (int j = 0; j < 1024; j++) {
        for (int i = 0; i < 1024; i++) {
            sum += matrix[i][j];  // 每次跳 1024 个 int
        }
    }
    return sum;
}

我在项目中遇到过类似的情况。当时一个图像处理模块，处理 4K 图片，按列遍历比按行遍历慢了将近 10 倍。原因很简单：C 语言中二维数组是按行存储的。按行遍历，每次访问下一个元素都在相邻的内存地址，缓存行（通常 64 字节）一次加载就能命中后续多个元素。按列遍历呢？每次跳过一个完整的行，缓存行加载的数据几乎全浪费了。

结构体布局优化：别让缓存“空转”

结构体布局，很多人不注意。其实这里门道很多。我见过一个项目，结构体里塞了各种字段，有经常访问的，有几乎不用的。结果呢？每次加载一个热点字段，顺带把一堆冷数据也拉进了缓存行，白白浪费了宝贵的缓存空间。

来看一个例子：

// 不好的布局：冷热数据混在一起
struct Player {
    int id;           // 热点：经常查询
    char name[32];    // 冷点：只在显示时用
    float x, y, z;    // 热点：每帧更新位置
    int level;        // 热点：经常检查
    char padding[40]; // 对齐填充
};

// 好的布局：按访问频率分组
struct PlayerHot {
    int id;
    float x, y, z;
    int level;
};

struct PlayerCold {
    char name[32];
    // 其他冷数据
};

把热点数据集中放在结构体开头，冷数据放后面。这样，当 CPU 加载 id 时，顺带把 x, y, z, level 也拉进了缓存。一次缓存行加载，四个热点字段全命中。效率翻倍。

预取指令：让 CPU 提前“猜”你要什么

现代 CPU 有硬件预取器，能自动识别顺序访问模式并提前加载数据。但有些场景，比如链表遍历、树搜索，访问模式是随机的，硬件预取就无能为力了。这时候，我们可以手动插入预取指令。

#include <xmmintrin.h>  // SSE 预取指令

void process_nodes(struct Node* head) {
    struct Node* cur = head;
    while (cur) {
        // 提前预取下一个节点
        _mm_prefetch((const char*)cur->next, _MM_HINT_T0);
        
        // 处理当前节点
        process(cur);
        
        cur = cur->next;
    }
}

这里 _MM_HINT_T0 表示将数据预取到所有级别的缓存（L1、L2、L3）。还有 _MM_HINT_T1（L2）、_MM_HINT_T2（L3）等。我一般用 T0，除非明确知道数据只会用一次。

知识体系总览

下面这张图，是我自己总结的缓存优化知识体系，你可以对照着看：

实战中的取舍

你可能会问：是不是所有代码都要这么优化？我的回答是：不一定。优化是有成本的，代码可读性、维护性也是重要考量。

我个人习惯是：

• 热点路径（比如游戏引擎的每帧更新、网络协议栈的数据包处理）—— 必须优化到极致。
• 冷路径（比如初始化、配置加载）—— 保持代码清晰即可，不必过度优化。
• 不确定时 —— 先用默认写法，然后 profile。用数据说话，不要凭感觉。

好了，今天就聊到这里。记住，缓存优化不是玄学，是实实在在的工程实践。下次写代码时，多想想你的数据在内存里是怎么排列的，CPU 是怎么访问的。嗯，你会发现，性能提升其实没那么难。

---