CPU 优化：从缓存到指令级并行
CPU 优化这块，很多人一上来就盯着代码层面的小技巧。但我做了这么多年性能调优，发现真正拉开差距的，是对 CPU 底层工作原理的理解。你想想看，如果连数据怎么在 CPU 里流转都不清楚，优化就只能是瞎猫碰死耗子。
这一章，我会把 CPU 优化的四个核心维度串起来讲：缓存原理、分支预测、指令级并行、减少上下文切换。它们不是孤立的，而是环环相扣的。
核心观点：CPU 优化的本质，就是让 CPU 尽可能「满负荷」工作，减少等待和空转。所有技巧都围绕这个目标展开。
CPU 缓存原理：为什么你的程序跑不快？
先问一个问题：CPU 每秒能处理几十亿条指令，但内存的访问速度呢？大概只有 CPU 的百分之一。这中间的差距，就是缓存的用武之地。
CPU 缓存分三级：L1、L2、L3。L1 最快也最小，L3 最大但相对慢一些。数据从内存到 CPU 寄存器，要经过这三级缓存。每一级缓存命中失败（cache miss），代价都会翻好几倍。
| 缓存级别 | 典型大小 | 访问延迟（CPU 周期） | 命中率影响 |
|---|---|---|---|
| L1 缓存 | 32KB - 64KB | 3-4 周期 | 极高，核心数据必须放这里 |
| L2 缓存 | 256KB - 512KB | 10-12 周期 | 中等，尽量让热点数据命中 |
| L3 缓存 | 2MB - 32MB | 30-40 周期 | 共享缓存，多线程竞争时关键 |
| 主内存 | 8GB - 512GB | 100-300 周期 | 能避免就避免 |
我在项目中遇到过这样一个场景：一个数据处理服务，每天要处理上亿条记录。最初代码写得很「优雅」，用了很多链表和指针跳转。结果呢？CPU 一直在等内存，利用率只有 20%。后来我把链表改成数组，把结构体对齐到缓存行大小，CPU 利用率直接飙到 85%。
这里有个关键概念叫缓存行。CPU 从内存加载数据，不是按字节加载的，而是按 64 字节一块加载。如果你访问了地址 A，那么地址 A 附近的 64 字节都会被加载到缓存里。这就是空间局部性的原理。
实战技巧：遍历数组时，按行遍历比按列遍历快得多。因为按行遍历能充分利用缓存行，按列遍历则会让缓存行频繁失效。我习惯在写循环时，总是让内层循环访问连续内存。
分支预测：CPU 的「猜谜游戏」
现代 CPU 都是流水线架构。一条指令要经过取指、译码、执行、写回等多个阶段。如果遇到条件分支（比如 if-else），CPU 不知道该走哪条路，怎么办？
它只能猜。猜对了，流水线顺畅跑。猜错了，就要清空流水线，重新加载正确的指令。这一来一回，浪费几十个周期。
分支预测器就是干这个的。它会记录历史分支的走向，然后预测下一次。预测准确率通常能到 90% 以上，但遇到随机数据或者规律性很差的分支，准确率会暴跌。
// 分支预测友好的写法
// 假设 data 是 0-255 的随机数
int sum = 0;
for (int i = 0; i < n; i++) {
if (data[i] > 128) { // 这个分支随机性高，预测准确率低
sum += data[i];
}
}
// 优化后：先排序，让分支有规律
std::sort(data, data + n);
for (int i = 0; i < n; i++) {
if (data[i] > 128) { // 排序后，前一段全 false，后一段全 true
sum += data[i];
}
}
我曾经在一个实时音频处理项目里，遇到过一个诡异的性能抖动。每次处理到某些音频帧时，延迟会突然飙升。排查了很久，发现是分支预测在作祟——音频数据里有一些随机噪声，导致分支预测准确率从 95% 掉到 60%。后来我把条件分支改成了查表法，抖动就消失了。
避坑指南：不要盲目排序。如果数据量很小（比如几十个元素），排序的开销可能比分支预测失败还大。我曾经吃过这个亏，排序后性能反而下降了。建议在数据量超过 1000 时再考虑这个优化。
指令级并行：让 CPU 同时干更多活
现代 CPU 不止一个执行单元。它可以同时执行多条指令，只要这些指令之间没有数据依赖。这就是指令级并行（ILP）。
但问题来了：我们的代码通常是顺序写的。编译器会帮我们做指令重排，但有时候它不够聪明。我们需要在写代码时，主动给 CPU 创造并行机会。
// 低并行度的写法
int a = b + c; // 指令 1
int d = e + f; // 指令 2，依赖指令 1 的结果吗？不依赖
int g = a + d; // 指令 3，依赖指令 1 和 2
// 编译器可能会这样重排：
// 指令 1 和指令 2 可以并行执行
// 指令 3 必须等前两个完成
你想想看，如果指令 1 和指令 2 之间没有依赖，CPU 就可以同时发射它们。但如果指令 2 依赖指令 1 的结果，那就只能串行执行了。
我个人的习惯是，在写循环体时，尽量把不相关的计算拆开。比如循环里既有加法又有乘法，如果它们不依赖彼此，就分开写，让 CPU 有机会并行执行。
关键点：指令级并行的瓶颈往往不是 CPU 不够快，而是代码里隐藏的数据依赖太多。用 perf 工具看 stalled-cycles 指标，如果这个值很高，说明你的代码在等待数据，并行度不够。
减少上下文切换：别让 CPU 做无用功
上下文切换，就是操作系统暂停当前线程，切换到另一个线程。每次切换，都要保存当前线程的寄存器状态、程序计数器、栈指针等，然后加载新线程的状态。这个过程很昂贵——一次切换大概要消耗几微秒。
几微秒听起来不多，但如果你的服务每秒要处理几万个请求，每个请求都触发几次上下文切换，那累积起来就是巨大的开销。
| 场景 | 上下文切换频率 | 性能影响 |
|---|---|---|
| CPU 密集型任务 | 低（线程数 ≈ CPU 核心数） | 几乎无影响 |
| IO 密集型任务 | 高（线程数 > CPU 核心数） | 明显，每次 IO 都可能触发切换 |
| 锁竞争激烈 | 极高 | 灾难性，线程都在等锁 |
我记得有一次优化一个网关服务，发现 CPU 利用率不高，但系统负载很高。用 vmstat 一看，上下文切换每秒几十万次。问题出在哪？线程池开得太大了，而且每个请求都用了同步 IO。后来我把线程数降到和 CPU 核心数一样，改用异步 IO，上下文切换直接降到几千次，吞吐量翻了一倍。
实用建议：用 pidstat -w 或者 perf stat -e context-switches 监控上下文切换。如果每秒超过 1 万次，就要警惕了。常见的优化手段包括：减少线程数、使用无锁数据结构、用协程替代线程。
知识体系总览
下面这张图，把 CPU 优化的四个维度串起来了。你可以看到，它们最终都指向同一个目标：减少 CPU 的空闲等待时间。
嗯，到这里 CPU 优化的四个核心维度就讲完了。缓存原理让你知道数据怎么流动，分支预测让你避免流水线停顿，指令级并行让你榨干 CPU 的每一点潜力，减少上下文切换让你避免操作系统层面的开销。这四个点，你只要吃透一个，就能在项目中看到明显的性能提升。