缓存基础：缓存层级、命中率与缓存一致性
缓存这件事，说白了就是计算机系统里最经典的"用空间换时间"策略。我刚开始做性能优化时，总觉得缓存是个黑盒子——直到有一次线上服务响应突然飙高，查了半天才发现是缓存命中率从99%跌到了70%。从那天起，我开始认真对待缓存的基础原理。
一、缓存层级：从L1到L3，速度的阶梯
CPU缓存不是单一的一块，而是分成多个层级。为什么呢？因为越快的存储器越贵，容量也越小。现代处理器通常有三层：
- L1缓存：最快，延迟约1~2个CPU周期。典型大小32KB~64KB，分指令缓存和数据缓存。
- L2缓存：稍慢，延迟约5~10个周期。大小256KB~512KB，通常每个核心独享。
- L3缓存：最慢但容量最大，延迟约20~40个周期。大小8MB~32MB，所有核心共享。
这里有个关键点：数据先在L1里找，找不到就去L2，再找不到去L3，最后才到主存。每往下一级，代价翻好几倍。我个人习惯在性能分析时先用perf stat -e cache-references,cache-misses看缓存命中情况，能快速定位问题。
典型延迟对比（CPU周期数）
L1: ~1 | L2: ~7 | L3: ~25 | 主存: ~100+
二、命中率：性能的晴雨表
命中率 = 缓存命中的次数 / 总访问次数。看着简单，但影响巨大。你想想看，如果命中率是99%，那平均访问延迟接近L1的1个周期；如果降到90%，平均延迟就变成0.9×1 + 0.1×100 ≈ 10个周期——性能直接差了一个数量级。
| 命中率 | 平均访问延迟（近似） | 性能影响 |
|---|---|---|
| 99.9% | 1.1周期 | 几乎不影响 |
| 95% | 6周期 | 可接受 |
| 85% | 16周期 | 明显变慢 |
| 70% | 31周期 | 严重瓶颈 |
我曾经接手过一个日志处理服务，吞吐量一直上不去。一看缓存命中率只有75%，发现原因是遍历数组时用了for i in range(len)而数组存在连续内存里，但每次访问都跨了缓存行。改成按缓存行大小对齐后，命中率直接跳到93%。所以，**数据局部性**比你想的更重要。
三、缓存一致性：多核世界的"交通规则"
多核CPU各自有私有缓存（L1/L2），如果两个核心同时读写同一块内存地址，就会产生数据不一致的问题。举个例子：核心A把变量x设为1，存到了自己的L1里；核心B从主存读到x还是0——这就是经典的不一致。
解决它的核心协议是MESI（Modified / Exclusive / Shared / Invalid）。每个缓存行有四种状态：
- Modified（修改的）：本核心独享且已修改，主存中的副本过时。
- Exclusive（独占的）：本核心独享，但内容与主存一致。
- Shared（共享的）：多个核心都有副本，且都符合主存。
- Invalid（无效的）：数据已失效，需要重新读取。
当一个核心要写数据时，必须通知其他核心将自己的副本置为Invalid。这个过程叫缓存一致性协议的事务。你想想看，每写一次都要广播，代价可不小。所以多线程编程里，尽量减少共享数据的写操作，能极大提升性能。
四、核心概念关系图
下面这张图概括了缓存层级、命中率和一致性之间的交互。建议你保存下来当备忘。
五、实践中的避坑指南
了解了理论，还得落实到代码里。我总结了几个最常见的缓存陷阱：
- 伪共享（False Sharing）：两个无关变量在同一个缓存行里，被核心A和B交替写→导致缓存行不断失效。解决方法：用
__attribute__((aligned(64)))或cacheline_pad。 - 缓存污染：一次性的大数据把有用的热点数据挤出了缓存。我曾经用
mmap读大文件，结果把热点数据全冲掉了。后来改用流式处理，加posix_fadvise告诉内核不要缓存。 - 扇出（Fan-out）不足：多线程里每个线程访问自己的独立数据，但实际在缓存中却映射到了同一组——导致相互踢出。这需要理解缓存关联度，建议查手册或用
cachegrind模拟。
perf stat -e cache-misses,bus-cycles看看是不是爆了。
缓存这三个概念——层级、命中率、一致性——是性能优化的地基。你以后看任何诊断数据，都会先问自己：数据在哪个层级？命中率是多少？会不会有伪共享？嗯，带着这些问题去分析，很多瓶颈就浮出水面了。