内存层次结构详解：L1/L2/L3缓存与TLB
说实话，很多做服务端开发的兄弟，写代码时眼里只有算法和数据结构，内存层次这块基本是黑盒。我做性能调优这么多年，发现但凡线上出现莫名其妙的抖动，十有八九跟缓存脱不了干系。说白了，CPU比内存快太多了——快了几个数量级，不搞几层缓存根本跑不动。
核心认知：CPU访问L1缓存大约1纳秒，访问主存大约100纳秒。这100倍的差距，直接决定了你的程序是顺滑还是卡顿。
为什么需要多层缓存
你先想一个问题：CPU主频动不动3GHz往上，一个时钟周期才0.3纳秒左右。而DDR4内存的访问延迟大概是70-100纳秒。这中间的空档怎么填？
设计内存层次结构的人，思路很直接——用更快但更贵的SRAM做缓存，把最常用的数据放进去。SRAM比DRAM快10倍，但成本也高10倍以上。所以层次就出来了：最快最小最贵的放最靠近CPU，慢点大点便宜的放远一点。
我个人习惯把缓存层次比作办公室的办公桌：L1是手边够得着的便签纸，L2是桌面抽屉，L3是隔壁的文件柜，内存是楼下的档案室。你拿东西的速度，跟距离直接挂钩。
L1、L2、L3缓存各自的作用
每个缓存层次，在设计上有明确的分工：
| 缓存级别 | 典型大小 | 访问延迟 | 位置 | 核心归属 |
|---|---|---|---|---|
| L1 | 32KB - 64KB | ~1ns (3-4 cycles) | 芯片内，核内 | 每个核心独享 |
| L2 | 256KB - 512KB | ~3-5ns (10-15 cycles) | 芯片内，核内 | 每个核心独享 |
| L3 | 8MB - 32MB | ~10-15ns (30-50 cycles) | 芯片内，跨核共享 | 所有核心共享 |
注意看L1的数字——32到64KB。就这么点空间，还得拆成指令缓存和数据缓存。我在项目中遇到过，一个遍历大数组的循环，因为数组元素跨度太大，L1缓存命中率直接掉到30%以下，性能腰斩。调优后把数据排布改成连续访问，命中率回到95%以上。
缓存行：一次拿一大块
你想想，如果CPU每次访问内存只读一个字节，那光是在总线路上来回折腾，效率就低到离谱。所以缓存每次都按行加载——标准大小是64字节。这块连续内存叫缓存行（Cache Line）。
这个设计对程序员意味着什么？举个例子：
// 坏例子：按列遍历二维数组
for (int j = 0; j < 1024; j++) {
for (int i = 0; i < 1024; i++) {
sum += arr[i][j]; // 每次跳跃1024个元素访问
}
}
// 好例子：按行遍历
for (int i = 0; i < 1024; i++) {
for (int j = 0; j < 1024; j++) {
sum += arr[i][j]; // 连续访问，缓存行友好
}
}性能差距？后者比前者快10倍以上。原因很简单：按行访问时，第一个元素加载就能把后续15个元素（64字节/4字节）免费带进缓存。按列访问，每次都要重新加载新的缓存行。
个人小技巧：写循环时，最先变化的维度应该是最小步长的那个。最好让内层循环的步长等于一个元素的大小，这样才能把缓存行利用到极致。
TLB：地址翻译的缓存
说到TLB（Translation Lookaside Buffer），很多人会忽略它。但我告诉你，TLB miss的代价往往比缓存miss还大。
现代操作系统用虚拟地址，每次内存访问都需要把虚拟地址翻译成物理地址。这个翻译过程需要查页表——页表又存在内存里。如果每次翻译都走一遍内存，性能直接垮掉。
TLB就是页表项的硬件缓存。它把最近用过的地址映射关系存下来，下次直接查。
| TLB级别 | 条目数 | 命中延迟 | miss代价 |
|---|---|---|---|
| L1 TLB (指令) | 64-128 | <1ns | 30-100 cycles |
| L1 TLB (数据) | 64-128 | <1ns | 30-100 cycles |
| L2 TLB | 512-2048 | ~3ns | 数百cycles |
TLB条目非常少，只有几十到几百个。而一个4KB页表项覆盖4KB内存。如果你的程序工作集（working set）超过了几百个4KB页面，TLB就会频繁miss。
避坑提醒：我曾经接手过一个大数据处理服务，内存占用不大，但响应时间剧烈波动。排查到最后，发现是大量随机访存导致TLB miss率高企。后来用大页（2MB Huge Pages）把TLB条目覆盖范围扩大512倍，TLB miss率从12%降到0.3%以下。
缓存一致性与伪共享
多核CPU最头疼的问题来了——每个核都有自己独立的L1和L2缓存。如果核A改了变量x，核B正好也在用x，怎么保证一致性？
硬件用的协议主要是MESI（Modified, Exclusive, Shared, Invalid）。说白了就是通过缓存行状态来协调：一个缓存行被某个核修改后，其他核里的同一缓存行标记为失效，下次访问必须从内存或别的核重新读取。
这就引出一个经典性能杀手：伪共享（False Sharing）。两个线程各自操作不同的变量，但这两个变量刚好落在同一个缓存行里。核A改了变量a，核B的缓存行失效；核B改变量b，核A的缓存行失效。两个核来回刷缓存，性能直接崩盘。
// 伪共享示例
struct data {
long long a; // 线程1只操作a
long long b; // 线程2只操作b
// a和b在同一个缓存行
};
// 解决方案：缓存行对齐
struct data {
long long a;
char pad[56]; // 填充到64字节
long long b;
};用填充来对齐缓存行，让a和b分别落到不同缓存行里，伪共享就解了。
如何感知缓存行为
光说不练假把式。看懂缓存行为，有几个实用手段：
- perf stat：查看缓存命中率、TLB miss率
- CPU性能计数器：L1-dcache-load-misses、dTLB-load-misses等内核事件
- valgrind --tool=cachegrind：模拟缓存行为，定位代码问题
我习惯在压测前先跑一轮perf stat，看看缓存命中率。如果L1 miss率超过10%，或者LLC miss率超过5%，基本可以断定内存访问模式有问题，值得深挖。
一张图看懂内存层次
下面我把整个内存层次结构和数据流动画出来，帮你建立整体认知：
这张图完整展示了数据从CPU核心到主存的路径。每次数据请求，先查L1，不中则查L2，再不中查L3，最后还是不中才去主存。每往下走一层，延迟翻倍甚至更多。
调优要抓住的重点
知道了内存层次是怎么工作的，调优就有方向了：
- 时间局部性：同一数据多次访问，尽量放在时间上靠近
- 空间局部性：连续访问相邻地址，利用缓存行预加载
- 避免伪共享：多线程操作的数据各自对齐到64字节边界
- 使用大页：减小TLB压力，特别适合大内存工作集场景
- 减少随机访存：指针追逐、链表遍历这种不连续模式，缓存很难友好
我的经验值：每次优化前先用perf抓一下缓存miss率，再针对性地改代码结构。不要盲目优化——有时候换个数据布局，比任何算法微调都管用。我记得有个典型案例，把B+树节点大小从默认4KB改成跟缓存行对齐的64字节后，范围查询性能提升了3倍。
内存层次结构是性能调优的底层密码。理解了它，你看代码的眼光就不一样了——不再是抽象的算法复杂度，而是每条数据在缓存间流动的路径。这种感知力，才是调优工程师真正的底气。