1. 内存基础与性能指标
各位同学，咱们这门课叫《内存占用压榨与算法调优》，第一脚必须踩稳。内存这东西，说白了就是程序的「工作台」。你工作台乱、工具远、抽屉深，干活肯定慢。我见过太多工程师，算法写得花里胡哨，结果被内存延迟一巴掌拍回解放前。所以，咱们先把内存的底裤扒干净。
1.1 内存层级：为什么你的程序跑不快？
现代计算机的内存，不是一层的，是好几层叠起来的。为什么这么搞？一个字：快又便宜不可兼得。
CPU 想要极速存取，但 SRAM 贵得要死；主存便宜，但慢得像蜗牛。于是工程师们搞了个折中——缓存层级。我习惯把这套体系叫做「内存金字塔」。
核心认知： 程序性能的瓶颈，往往不在 CPU 算力，而在数据能不能及时喂到 CPU 嘴边。这就是「内存墙」。
你看这张图，从上到下，延迟差了六个数量级。L1 缓存访问一次只要 1 纳秒，去主存拿数据要 100 纳秒，要是触发缺页中断去磁盘读……嗯，那基本就是毫秒级别了。我曾经在一个日志处理系统里，发现某个模块性能奇差，一查，原来是数据结构和锁设计导致频繁触发 swap，程序大部分时间在等磁盘。你说冤不冤？
1.2 关键性能指标：拿数据说话
搞内存优化，不能靠感觉。你得盯死三个指标：延迟、带宽、命中率。我每次做性能分析，第一件事就是把这几个数拉出来看看。
| 指标 | 定义 | 典型值 | 我的关注点 |
|---|---|---|---|
| 延迟 (Latency) | 从发起访问到拿到数据的时间 | L1: ~1ns, L2: ~5ns, L3: ~15ns, 主存: ~100ns | 延迟越低越好，但受物理限制 |
| 带宽 (Bandwidth) | 单位时间内能传输的数据量 | DDR4: ~20GB/s, L1: ~1TB/s | 带宽不足时，考虑数据压缩或预取 |
| 命中率 (Hit Rate) | 在缓存中找到数据的概率 | L1: ~90%, L2: ~80%, L3: ~60% | 命中率低，说明局部性差，得改算法 |
我的小习惯： 拿到一个性能问题，先看缓存命中率。如果 L1 命中率低于 80%，别急着优化代码逻辑，先看看数据访问模式是不是「跳着走」的。改改数据结构，往往比优化循环体有效十倍。
你想想看，为什么有时候你优化了算法复杂度，程序反而没快多少？大概率是缓存没伺候好。我记得有一次优化一个排序模块，把冒泡换成快排，理论上快了一个数量级，结果实测只快了 20%。一查 perf，L1 数据缓存缺失率高达 40%。原来数据太大，频繁换入换出，CPU 大部分时间在等内存。后来改成原地排序 + 分块处理，才真正起飞。
1.3 性能分析工具：你的第三只眼
光有理论不行，得上家伙。我常用的三件套：perf、Valgrind、火焰图。它们各有侧重，配合起来基本能覆盖 90% 的内存性能问题。
1.3.1 perf：Linux 性能分析瑞士军刀
perf 是内核自带的，轻量、低开销。我最常用它来采样 CPU 事件和缓存事件。
# 采样缓存缺失事件
perf stat -e cache-misses,cache-references,L1-dcache-load-misses ./my_program
# 采样 CPU 热点
perf record -g ./my_program
perf report -g graph你看，第一行直接告诉你缓存命中率。第二行能画出调用链，哪个函数最耗 CPU 一目了然。我曾经用 perf 抓到一个诡异的性能抖动——某个函数平时只跑 1ms，偶尔跳到 100ms。一看 perf report，发现是内存分配器在触发系统调用，导致上下文切换。后来换成 tcmalloc，问题解决。
注意： perf 的采样是统计性的，不是精确的。对于极短函数（微秒级），采样可能不准。这时候可以结合 perf stat -d 看硬件计数器。
1.3.2 Valgrind：内存错误的照妖镜
Valgrind 的强项是检测内存泄漏、越界访问、使用未初始化内存。它通过模拟 CPU 来运行程序，所以慢——大概慢 10~20 倍。但值得等。
# 检测内存泄漏
valgrind --leak-check=full ./my_program
# 检测越界和未初始化
valgrind --tool=memcheck --track-origins=yes ./my_program我曾经接手过一个遗留服务，每隔几天就莫名其妙崩溃。用 Valgrind 一跑，好家伙，一个全局数组在并发写入时越界了，把旁边的函数指针给覆盖了。这种 bug，靠肉眼看代码根本看不出来。
避坑指南： Valgrind 对 JIT 编译的程序（如 Java、Node.js）效果有限。对于这类程序，可以考虑用 AddressSanitizer（ASan）替代，编译时加 -fsanitize=address 即可。
1.3.3 火焰图：性能瓶颈的可视化利器
火焰图是 Brendan Gregg 的杰作。它把 perf 的采样数据变成一张图，横轴是时间（或采样数），纵轴是调用栈。哪个函数「占的宽度」越大，就是热点。
# 生成火焰图
perf record -F 99 -g ./my_program
perf script | ./stackcollapse-perf.pl | ./flamegraph.pl > flame.svg我习惯先看火焰图的「山顶」——那些最宽的函数。如果山顶是库函数（如 memcpy、malloc），说明你的数据搬运或分配有问题。如果山顶是你自己的业务函数，那就得优化算法了。
嗯，这里要注意：火焰图是采样结果，采样频率（-F 99）决定了精度。我一般设 99Hz，既够用又不至于产生太多数据。
1.4 本章小结
这一章咱们把内存的底子打了一遍。记住三件事：
- 内存层级：L1/L2/L3/主存/虚拟内存，延迟差六个数量级。程序性能 = 数据尽量待在顶层。
- 三个指标：延迟、带宽、命中率。优化前先看数据，别瞎猜。
- 三把刀：perf 看热点，Valgrind 查错误，火焰图可视化。配合使用，效率翻倍。
我个人习惯，每接手一个新模块，第一件事就是跑一遍 perf stat，看看缓存命中率。如果低于 80%，我会直接标记为「待优化」。这个习惯帮我省了无数 debug 时间。