缓存优化：榨干CPU缓存的最后一滴性能

可视化演示

展示CPU三级缓存层次结构与命中率影响、缓存行对齐策略、以及伪共享问题的检测与解决。

缓存层级体系

厨房里的备餐台不是一整块，而是有三层：手边的调料架是 L1，中岛台是 L2，门口的大推车是 L3。大厨越常用的东西放得越近，越不常用的东西放得越远。CPU 内部也一样，L1 离计算核心最近，最快但只有几十 KB；L2 稍远稍大；L3 容量最大，被多个核心共享，速度仍然比内存快一个数量级。

内存与 CPU 的速度差有多大？访问一次 L1 大约只要 1 纳秒，访问内存却要 80 纳秒以上。如果程序每次取数都命中 L1，大厨几乎不需要等待；一旦未命中，CPU 就不得不放下手里的活，眼巴巴等内存把数据搬过来。因此，命中率成了决定程序快慢的关键指标。

平均访存时间可以写成命中率 H 的加权平均：

回到厨房：备餐台越高级越贵，所以没人会把整个仓库搬上案板。缓存优化的第一步，就是认清每层台面的容量与速度，把最频繁使用的数据尽量往最靠近手边的地方放。

缓存行与对齐

备餐台不是按一粒盐、一撮糖来搬运的，而是用一个个托盘，一次端 64 字节。CPU 从内存读数据也不是按字节读，而是按缓存行读，主流 CPU 一行通常是 64 字节。只要程序访问了某个地址，它所在的整行都会被加载进缓存。

既然一行 64 字节，CPU 必须知道某个地址落在哪一行。行号的计算方式很简单：

缓存行概念还引出了一个经典陷阱：如果两个线程各自修改不同的变量，但这两个变量恰好落在同一个 64 字节托盘上，那么只要一个线程写数据，另一个线程的缓存行就会被强制失效。两个厨师本来各用各的盐和糖，却因为放在同一个托盘上互相抢来抢去，这就是伪共享（false sharing）。解决办法，是让热点变量各自占满一个缓存行，或者改用线程私有数据。

数据局部性

大厨炒菜讲究“顺手”：切好的葱姜蒜按使用顺序排成一排，炒完这道菜马上用下一道菜的料。程序访问内存也有两种“顺手”：时间局部性是说同一个数据在短时间内会被反复使用；空间局部性是说用了一个地址，旁边的地址大概率马上也会用到。

空间局部性在数组遍历中体现得最明显。C/C++ 的二维数组按行主序存储，也就是一行一行连续摆放：

因此，按行遍历二维数组是“顺着托盘一行行拿”，而按列遍历则是“跳到远处再回来”，每次跨行都会丢掉空间局部性。除了数组，结构体布局也要考虑这一点：经常一起访问的字段应该放在紧密相邻的位置，避免为了拿一个字段而把整个缓存行都拖进来。

编译期优化

大厨拿到菜谱会先做一次“内部排练”：把重复的翻锅动作合并，把不必要的停顿去掉。编译器也做类似的事，但它有个前提——必须确认数据之间没有互相影响的别名。C/C++ 中可以用 restrict 告诉编译器：两个指针不会指向同一块内存，编译器就能放心地并行化、向量化。

另一个常用优化是循环展开。循环本身有计数器自增、条件判断等开销，展开后一次迭代做多件事，减少分支次数：

不过，循环展开不是越猛越好。展开因子过大，代码体积膨胀，指令缓存 L1 I-cache 装不下，反而把“取指令”拖慢。编译器在 -O3 下通常会自动做合理的展开，手动优化前最好先用 profiling 数据证明展开真的有收益。

预取策略

大厨备菜时会让帮工提前从仓库取食材，不用等锅热了才跑去拿。CPU 也有类似的“帮工”：硬件预取器发现你按固定步长访问内存，会主动把后面的数据搬进缓存。软件预取则是程序员显式调用 __builtin_prefetch 或 prefetcht0，告诉 CPU“接下来要用某个地址”。

预取的关键是距离：提前太多，食材占着备餐台却不做菜，真正要用的菜反而没地方放；提前太少，货还没送到，CPU 还是得等。理想距离由内存延迟和单次迭代耗时决定：

预取也有明显的边界：它只对规则、可预测的访问模式有效。链表、二叉树、随机跳转这类“下一站在哪完全看内容”的访问，预取器猜不出来，提前下发指令只会浪费缓存空间。

循环分块

十桌客人同时点菜，大厨不会一次把十桌的配菜全搬上案板，而是一桌一桌备，让每桌的原料在台面上用完再换下一桌。程序里的大数组也一样，如果循环一口气扫完整个矩阵，前面的数据可能早就被后面的数据挤出缓存。

循环分块（tiling）就是把大循环切成适合缓存容量的子块，让数据在块内反复复用。子块边长 B 不能拍脑袋，要按缓存容量估算：

分块后，每一小块数据被加载进缓存后，会在多次计算中被反复读到，这就是“复用提升”。矩阵乘法是循环分块最经典的受益者：不优化时每个元素反复从内存读，优化后大部分读写都命中缓存，性能差距可达数倍。

调优工具

大厨说“我炒菜很快”不算数，要拿秒表计时才算数。缓存优化同样不能靠直觉，要用工具测。perf stat 可以报告缓存命中率、缓存缺失数；perf c2c 专门分析缓存行上的跨核竞争，是伪共享的“照妖镜”；Cachegrind 可以模拟缓存行为；火焰图则能快速定位热点函数。

评估缓存效果最常用的指标是缺失率：

在实际调优中，先跑一遍基线，标记“缺失最多、耗时最长”的循环；再用 perf c2c 确认是否存在伪共享；最后针对热点做局部修改。每一步都重新测量，避免“优化了个寂寞”。

工程实践

优化餐厅流程和优化缓存是同一件事：先记录现状，再改流程，最后用数据对比。缓存优化的工程实践不需要一上来就写汇编，而是按“测量—定位—重构—验证”的节奏推进。

常用提速公式很简单：

真正落到代码里，工程实践通常包括：把结构体中高频访问的字段放到一起；把多线程共享的计数拆成线程私有，再做周期合并；在 x86 和 ARM 上分别验证缓存行大小；用 perf stat 的命中率变化确认每一版修改的效果。缓存优化没有银弹，只有把“数据放在离计算近的地方”这一原则执行到底。

AI 应用场景

Python 演示

import time  def build_matrix(n):    return [[i + j for j in range(n)] for i in range(n)]  def sum_row_major(mat):    total = 0    n = len(mat)    for i in range(n):        for j in range(n):            total += mat[i][j]    return total  def sum_col_major(mat):    total = 0    n = len(mat)    for i in range(n):        for j in range(n):            total += mat[j][i]    return total  def bench(fn, mat):    t0 = time.perf_counter()    for _ in range(5):        fn(mat)    return time.perf_counter() - t0  def main():    n = 2000    mat = build_matrix(n)    row_time = bench(sum_row_major, mat)    col_time = bench(sum_col_major, mat)    print("row major: {:.3f}s".format(row_time))    print("col major: {:.3f}s".format(col_time))    print("speedup: {:.2f}x".format(col_time / row_time))  if __name__ == "__main__":    main()

1. total += mat[i][j]同一行内 j 连续变化，Python 列表虽然是一维数组的数组，但每行内部仍是连续内存，能利用空间局部性。
2. total += mat[j][i]固定列号、外层 i 变化，每次都要跳到不同行，缓存行被频繁浪费。
3. bench(fn, mat)每个函数跑 5 次取总耗时，减少调度和噪音干扰。
4. speedup = col_time / row_time用列遍历时间除以行遍历时间，量化局部性带来的差距。

常见误区

面试题