内存层次结构：从寄存器到磁盘的提速之道
你有没有想过，CPU跑得那么快，为什么还要等内存？
我刚开始做性能分析时，经常被这个问题卡住。明明CPU主频已经3GHz，一跑业务却发现大量时间花在“闲着等数据”。这背后的罪魁祸首，就是内存层次结构。
说白了，CPU就像个超级跑车，内存是普通公路，缓存才是赛道。数据在缓存里，CPU就能飙起来；数据在主存里，就得减速；数据到了SWAP，那基本是堵车状态。
我习惯把内存层次看作一个金字塔。越靠近CPU，越快、越贵、越小。反之，越远越慢、越便宜、越大。今天的课程，我们一起把这个金字塔拆开看看。
核心记忆点： 内存层次结构的目标是用硬件的“局部性”来对抗冯·诺依曼瓶颈。局部性越好，缓存命中率越高，CPU越少等待。
1. L1缓存：CPU的贴身助手
L1缓存是离CPU核心最近的存储。通常分成两部分：指令缓存（L1i）和数据缓存（L1d）。
- L1i：存放CPU即将执行的指令。
- L1d：存放CPU即将读写的数据。
它有多快？
- 访问延迟：约2-4个CPU周期。以3GHz为例，就是0.6-1.3纳秒。
- 典型大小：每个核心32KB-64KB。没错，就几十KB。
我个人习惯先检查L1命中率。如果这里命中率低，说明代码需要优化循环——**数据根本没被放到CPU身边**。
我的经验：用perf stat -e L1-dcache-load-misses,L1-dcache-loads ./myapp可以看L1数据cache的命中情况。命中率低于90%，就该考虑优化了。
2. L2缓存：第二道防线
L2缓存是L1的保姆。当L1没命中，CPU会立刻向L2请求数据。
- 访问延迟：约10-20个CPU周期。大概是L1的5倍。
- 典型大小：每个核心256KB-512KB。有些服务器CPU把L2做到1MB以上。
- 共享策略：有些CPU让每个核心独享L2，有些是多个核心共享。
你想想看，L2比L1慢了5倍，但容量翻了近10倍。这是典型的“用时间换空间”。
记得我在调优一个数据库查询引擎时，发现L2命中率特别低。后来排查发现，代码里有个大哈希表，**数据结构太大了，L1装不下，连L2都装不下**。改为更紧凑的跳表后，L2命中率从60%升到了95%，查询延迟直接降了40%。
3. L3缓存：最后也是最大的缓存
L3是所有核心共享的最后一级缓存。它的核心价值是减少跨核心的数据同步开销和访问主存。
- 访问延迟：约30-60个CPU周期。
- 典型大小：几MB到几十MB。比如Intel的Xeon，L3一般是15-30MB。
- 命中率：理想状态下，L3命中率应该超过95%。
| 存储层次 | 典型大小 | 访问延迟 | 带宽（近似） |
|---|---|---|---|
| L1缓存 | 32KB-64KB/核心 | 2-4周期（~1ns） | ~500GB/s |
| L2缓存 | 256KB-1MB/核心 | 10-20周期（~4ns） | ~200GB/s |
| L3缓存 | 10-50MB（共享） | 30-60周期（~15ns） | ~100GB/s |
我发现很多工程师只关心CPU频率，却不知道L3命中率低可能是问题的真正原因。比如高并发服务，如果L3频繁缺失，CPU就会频繁去找主存，那延迟直接翻了一个数量级。
4. 缓存行与局部性：让硬件跑得更顺
缓存不是按字节读写的，而是按“缓存行”。通常是64字节。
为什么会这样？
因为局部性原理：如果你访问A，很可能也访问A附近的数据。大块搬运能减少通信开销。
这就引出了两个重要概念：
- 时间局部性：同一数据被反复访问。比如循环变量。
- 空间局部性：相邻地址被连续访问。比如遍历数组。
我遇到过的一个典型坑：**伪共享（False Sharing）**。两个线程各自修改不同变量，但这两个变量恰好在同一缓存行。一个线程写变量A，导致整个缓存行失效，另一个线程的变量B也被迫重新加载。
我曾经踩过的坑：一个多线程计数器框架，多个核心争抢同一个锁，锁和数据都在同一缓存行。后来我用__attribute__((aligned(64)))把数据对齐到缓存行边界，吞吐量直接涨了3倍。
5. 主存（RAM）：大容量但慢速
主存是内存层次中的主力存储。DDR4、DDR5这些，我们天天打交道。
- 访问延迟：约60-100纳秒。换算成CPU周期，就是180-300周期。
- 典型大小：8GB-512GB。
- 带宽：DDR5-4800约38.4GB/s。跟L1差了一个数量级。
我的调优原则：**能用缓存解决的，绝不去主存**。如果发现主存带宽被跑满，说明代码的局部性差，或者数据量远超缓存容量。
6. SWAP：最后的“毒药”
SWAP，就是把内存数据换到磁盘上。磁盘的典型延迟是几毫秒，比主存慢十万倍。
我遇到过SWAP导致数据库响应从1ms暴涨到200ms的例子。一次磁盘IO几毫秒，几千次请求就卡死了。
为什么会这样？
因为操作系统在内存不足时，会把不常用的内存页换到磁盘。当程序需要访问这些页时，系统必须“缺页中断”，从磁盘读回数据。
| 指标 | 含义 | 警告阈值 |
|---|---|---|
| si（swap in） | 从磁盘读入内存的页数 | 持续大于0 |
| so（swap out） | 从内存写入磁盘的页数 | 持续大于0 |
| swappiness | 系统倾向使用SWAP的程度（0-100） | 默认60，服务器我建议设10-20 |
我的建议：SWAP不能完全关掉，有些守护进程需要它。但可以调低vm.swappiness=10，让系统除非万不得已，才用SWAP。
检查：sysctl vm.swappiness，临时改：sysctl -w vm.swappiness=10，永久改写在/etc/sysctl.conf。
7. 内存层次结构全景图
下面这张图，把这节课的核心串起来。记住这个金字塔，性能调优的“第一性原理”就在这。
8. 实战监控快查
这里是我日常排查用的命令集。我把它当作“内存层次健康检查表”。
# 查看缓存命中率
perf stat -e cache-references,cache-misses ./myapp
# 查看L1/L2/L3具体数据（Intel平台）
perf stat -e L1-dcache-load-misses,L1-dcache-loads,L2-load-misses,LLC-load-misses ./myapp
# 查看内存和SWAP使用情况
vmstat 1 5警告：用perf需要内核支持。有些云环境或容器可能没开。先跑perf list看看事件列表。
9. 小节：内存层次结构透视图
你想想看，从L1到SWAP，延迟差了10万倍以上。性能调优的本质，就是让热数据尽可能留在靠近CPU的地方。
我一般遇到性能问题，第一步就是查缓存命中。如果L2/L3命中率低于90%，我会优先看数据布局和访问模式。如果SWAP活跃，我会直接加内存或优化内存分配。