📚 课程目录第4章内存操作数优化

4. 内存操作数优化：内存寻址模式、对齐访问的重要性、缓存行与内存操作数的关系

内存操作数，说白了就是指令里跟内存打交道的那些家伙。很多开发者觉得写代码只要逻辑对就行，内存怎么访问是编译器的事。嗯，我以前也这么想，直到有一次线上服务性能怎么都上不去，perf 一看，L1 cache miss 高得离谱。从那以后，我再也不敢小看内存操作数的写法了。

这一节，咱们就聊聊内存寻址模式、对齐访问，还有缓存行跟内存操作数之间那些「剪不断理还乱」的关系。

4.1 内存寻址模式：你的数据到底在哪？

CPU 访问内存不是直接给个地址就完事，它有一套寻址模式。不同的寻址模式，生成的指令长度和执行周期都不一样。

我习惯把 x86-64 下常见的寻址模式分成这几类：

寻址模式	语法示例	有效地址计算	典型场景
立即数寻址	`mov eax, 42`	操作数在指令中	常量赋值
寄存器寻址	`mov eax, ebx`	操作数在寄存器	寄存器间传值
直接寻址	`mov eax, [0x8048000]`	地址 = 立即数	访问全局变量
寄存器间接寻址	`mov eax, [ebx]`	地址 = 寄存器值	指针解引用
基址+变址寻址	`mov eax, [ebx+ecx*4]`	地址 = 基址 + 变址*比例	数组遍历
基址+偏移寻址	`mov eax, [ebx+16]`	地址 = 基址 + 偏移	结构体成员访问
SIB 寻址	`mov eax, [ebx+ecx*4+8]`	地址 = 基址 + 变址*比例 + 偏移	二维数组、对象池

我的习惯：能用基址+偏移搞定的，就别上 SIB。SIB 虽然灵活，但解码更复杂，指令长度也多 1-2 字节。在热点路径上，少一个字节就是多一分性能。

你想想看，一个 for 循环里如果每次都用 SIB 寻址，CPU 每次都要多算一次加法。虽然单次看起来没多少，但循环一千万次，差距就出来了。

4.2 对齐访问：为什么地址必须是 4 的倍数？

对齐访问，指的是数据的起始地址必须是其大小的整数倍。比如 4 字节的 int，地址必须是 4 的倍数；8 字节的 double，地址必须是 8 的倍数。

为什么会这样？

因为 CPU 从内存读数据，不是一次读 1 个字节，而是按「总线宽度」来读。现代 CPU 一次最少读 8 字节（64 位），甚至 16 字节（128 位）。

如果数据没对齐，会发生什么？

跨边界访问：一个 4 字节的 int 如果放在地址 2，它就会跨越两个 4 字节的边界。CPU 需要读两次内存，再把结果拼起来。
性能惩罚：在 x86 上，未对齐访问通常慢 2-3 倍。在 ARM 上，直接触发异常。
原子性破坏：未对齐的变量不能保证原子读写，多线程下容易出问题。

  核心原则：结构体成员按大小降序排列，或者用 __attribute__((packed)) 时要格外小心。我曾经接手过一个网络协议解析模块，结构体里字段乱排，导致每个包解析都触发未对齐访问，性能直接腰斩。

来看一个对比：

// 未对齐版本（性能差）
struct __attribute__((packed)) BadPacket {
    uint8_t  flag;      // 1 字节
    uint32_t seq;       // 4 字节，地址从 1 开始，未对齐
    uint16_t crc;       // 2 字节，地址从 5 开始，未对齐
};

// 对齐版本（性能好）
struct GoodPacket {
    uint32_t seq;       // 4 字节，地址 0
    uint16_t crc;       // 2 字节，地址 4
    uint8_t  flag;      // 1 字节，地址 6
    // 末尾填充 1 字节，使结构体大小为 8 的倍数
};

你看，只是调整了一下成员顺序，访问速度就能差出一大截。这就是对齐的威力。

4.3 缓存行与内存操作数：别让数据「打架」

现代 CPU 的缓存是以「缓存行（Cache Line）」为单位管理的。x86-64 上，一个缓存行通常是 64 字节。

这意味着什么？

你访问地址 A 时，CPU 会把 A 所在的整个 64 字节块都加载到缓存里。如果两个线程各自访问不同的变量，但这两个变量恰好在同一个缓存行里，就会发生「伪共享（False Sharing）」。

伪共享的后果很严重：

线程 1 修改变量 X，导致整个缓存行失效。
线程 2 的变量 Y 也在同一行，被迫重新加载。
两个线程互相「踢」对方的缓存，性能急剧下降。

我曾经踩过的坑：一个多线程统计模块，每个线程维护一个计数器，放在一个结构体数组里。结果这些计数器挨着放，刚好挤在一个缓存行里。8 个线程跑起来，性能还不如单线程。后来在每个计数器后面补了 64 字节填充，性能直接翻了 6 倍。

下面这张图展示了缓存行与内存操作数的关系：

4.4 实战策略：写出缓存友好的内存操作数

光知道理论不够，得能落地。我总结了几个实战策略：

按顺序访问内存：遍历数组时，按地址递增顺序访问。这样能最大化利用缓存行的预取机制。
避免跨缓存行访问：如果一个数据结构经常被并发修改，用 alignas(64) 或 __attribute__((aligned(64))) 让它对齐到缓存行边界。
结构体拆分：把「读多写少」和「读少写多」的字段分开放在不同的结构体里，减少伪共享。
使用局部变量：频繁访问的指针或数组索引，先加载到局部变量里。编译器更容易把它优化到寄存器。
慎用位域：位域虽然省空间，但访问时往往需要额外的移位和掩码操作，而且容易导致未对齐访问。

一个小技巧：在性能关键路径上，可以用 __builtin_prefetch 手动预取数据。不过别滥用，预取太早会把缓存行踢出去，太晚又没效果。我一般只在循环步长很大的场景下用。

最后说一句，内存操作数的优化，本质上就是让 CPU 的缓存子系统「舒服」。你顺着它的脾气写代码，它就能给你跑出漂亮的数据。别跟硬件对着干，吃亏的总是自己。