4、内存访问延迟：CPU缓存层级结构、TLB缺失、NUMA架构下的内存访问优化
说到性能优化，内存访问延迟是个绕不开的话题。我见过太多人把精力全放在算法复杂度上，结果程序跑起来还是慢——一查，发现CPU大部分时间都在等内存。说白了，内存才是现代计算机系统里最大的瓶颈之一。
今天我们就来聊聊内存访问延迟的三个核心问题：CPU缓存怎么工作的、TLB缺失为什么那么疼、以及NUMA架构下怎么避免踩坑。
4.1 CPU缓存层级结构：从L1到主存的延迟鸿沟
先看一组数字。这是我个人习惯记在脑子里的延迟参考值：
| 存储层级 | 典型延迟 | 大小 |
|---|---|---|
| L1缓存 | ~1ns (3-4个CPU周期) | 32KB-64KB |
| L2缓存 | ~4ns (10-12个周期) | 256KB-512KB |
| L3缓存 | ~10ns (30-40个周期) | 8MB-32MB |
| 主存 | ~100ns (300+个周期) | GB级别 |
看到没？L1和主存之间差了整整两个数量级。你想想看，如果程序频繁访问主存，CPU大部分时间都在空转等待数据。这就是所谓的「内存墙」问题。
我在项目中遇到过这样一个案例：一个数据处理服务，吞吐量上不去。用perf一看，L1缓存命中率只有60%左右，L3命中率也才80%。后来我们把热点数据做了结构体对齐和缓存行填充，L1命中率直接拉到95%以上，吞吐量翻了一倍。
缓存行与伪共享
CPU缓存是以缓存行（Cache Line）为单位加载的，通常是64字节。这意味着你访问一个4字节的int，CPU会把相邻的60个字节也一起拉进来。
好处是空间局部性——如果你接下来访问相邻数据，直接命中缓存。坏处呢？就是伪共享（False Sharing）。
4.2 TLB缺失：被忽视的性能杀手
TLB（Translation Lookaside Buffer）是CPU内部的一个小缓存，用来加速虚拟地址到物理地址的转换。它的命中率直接影响内存访问速度。
为什么会这样？因为每次内存访问都需要做地址翻译。如果TLB命中，翻译过程几乎不花时间。但如果TLB缺失，CPU就得去查页表——这个过程可能要走好几级内存，延迟飙升。
TLB的条目数非常有限。一般L1 TLB只有几十个条目，L2 TLB也就几百个。如果你的程序访问的内存页面太多，TLB就会频繁缺失。
大页优化
一个常见的优化手段是用大页（Huge Pages）。默认的页大小是4KB，如果换成2MB的大页，同样的TLB条目能覆盖的内存范围扩大了512倍。
嗯，这里要注意：大页不是银弹。它适合那些内存占用大、访问模式稳定的应用，比如数据库、搜索引擎。对于小内存应用，大页反而可能浪费。
4.3 NUMA架构下的内存访问优化
NUMA（Non-Uniform Memory Access）是现代多路服务器的主流架构。说白了，每个CPU有自己的本地内存，访问本地内存快，访问远程内存慢。
延迟差异有多大？我实测过：本地内存访问大约100ns，跨NUMA节点的远程内存访问要150-200ns。如果程序频繁跨节点访问，性能损失非常明显。
NUMA感知编程
优化NUMA的核心原则就一条：让数据尽量靠近访问它的CPU。
- 内存绑定：用numactl或libnumma API，把线程和它使用的内存绑定到同一个NUMA节点
- 线程绑定：用pthread_setaffinity_np把线程固定在某个CPU核心上
- 数据结构拆分：每个NUMA节点维护一份本地数据副本，避免跨节点访问
NUMA平衡与干扰
Linux内核有自动NUMA平衡（Auto NUMA Balancing）机制，它会尝试把页面迁移到访问它的线程所在的节点。听起来不错，但实际效果嘛...我建议你关掉它。
为什么？因为页面迁移本身有开销，而且可能导致延迟抖动。对于延迟敏感的应用，手动控制比交给内核靠谱得多。
4.4 知识体系总览
下面这张图是我自己整理的，把本章的核心逻辑串起来了：
这张图把三个核心问题串起来了。你会发现，不管是缓存、TLB还是NUMA，最终目标都是一样的：让CPU少等内存。
4.5 实战建议
最后，给你几个可以直接上手的建议：
- 先用perf stat看看缓存命中率。如果L1命中率低于80%，说明你的数据局部性有问题。
- 检查TLB缺失率。如果很高，试试大页。我一般先用2MB大页，不够再用1GB。
- NUMA环境下，用numactl --hardware看看拓扑。然后确保你的线程和内存分配在同一个节点上。
- 关掉自动NUMA平衡。除非你确定它不会带来抖动。
好了，内存访问延迟这块就聊到这儿。记住一句话：优化内存访问，就是优化CPU的等待时间。下一节我们会聊到更具体的工具和方法，到时候见。
公众号:蓝海资料掘金营，微信deep3321