4、缓存优化策略：L1/L2/L3缓存命中率提升、缓存行对齐、预取指令使用

说到服务器芯片性能调优，缓存这块儿绝对是绕不开的核心战场。我见过太多团队，CPU主频拉得老高，内存带宽也够，可实际跑业务就是慢。一查，好家伙，缓存命中率惨不忍睹。说白了，你的数据在哪儿，决定了你的程序跑多快。

4.1 缓存层次结构：为什么L1比L3快那么多？

先简单回顾下缓存的结构。现代服务器CPU通常有三层缓存：

缓存层级	典型大小	延迟（CPU周期）	特点
L1	32KB - 64KB	3-4 cycles	分指令和数据，每个核心独享
L2	256KB - 1MB	10-12 cycles	每个核心独享
L3	8MB - 64MB	30-50 cycles	所有核心共享

你想想看，访问一次L1只要3个周期，而访问主存要300多个周期。这差了100倍！所以优化的核心思路就一条：让数据尽可能待在L1里。

4.2 缓存行对齐：别让你的数据跨线

缓存的最小单位不是字节，而是缓存行（Cache Line）。x86架构下，一个缓存行是64字节。这意味着，CPU从内存加载数据时，一次拉64字节。

问题来了：如果你的一个关键结构体，刚好跨了两个缓存行，会发生什么？

嗯，CPU得读两次。更糟的是，如果两个核心同时操作这个结构体的不同字段，还会触发伪共享（False Sharing）。

解决方案很简单——缓存行对齐：

// 错误示例：两个变量可能落在同一缓存行
struct shared_data {
    int producer_count;
    int consumer_count;
};

// 正确示例：用填充字节强制分离
struct shared_data {
    int producer_count;
    char padding[60];  // 填充到64字节
    int consumer_count;
};

// 或者用编译器属性（GCC/Clang）
struct __attribute__((aligned(64))) shared_data {
    int producer_count;
    int consumer_count;
};

4.3 提升L1/L2命中率：数据布局的艺术

我个人习惯把数据布局优化放在首位。为什么？因为这是性价比最高的手段。你不需要改算法，只需要调整数据在内存里的排列方式。

4.3.1 结构体字段重排

把经常一起访问的字段放在一起。比如一个网络包处理结构体：

// 低效布局：热点字段分散
struct packet {
    uint64_t timestamp;   // 热点
    uint32_t payload_len; // 非热点
    uint16_t src_port;    // 热点
    uint16_t dst_port;    // 热点
    char data[1024];      // 非热点
};

// 高效布局：热点字段集中在前
struct packet {
    uint16_t src_port;    // 热点
    uint16_t dst_port;    // 热点
    uint64_t timestamp;   // 热点
    uint32_t payload_len; // 非热点
    char data[1024];      // 非热点
};

你想想看，CPU加载第一个字段时，顺带把附近的热点字段也拉进缓存了。这就是所谓的空间局部性。

4.3.2 数组结构体 vs 结构体数组

这个选择很关键。如果你的代码是逐对象处理所有字段，用AoS（Array of Structs）。如果是批量处理某个字段，用SoA（Struct of Arrays）。

// AoS：适合逐对象处理
struct particle {
    float x, y, z;
    float vx, vy, vz;
    float mass;
};
struct particle particles[10000];

// SoA：适合批量处理位置更新
struct particles {
    float x[10000];
    float y[10000];
    float z[10000];
    float vx[10000];
    float vy[10000];
    float vz[10000];
    float mass[10000];
};

我在做物理引擎优化时，把AoS改成SoA后，L1缓存缺失率从35%降到了12%。效果立竿见影。

4.4 预取指令：让数据提前到位

硬件预取器已经很聪明了，但遇到不规则访问模式时，它还是无能为力。这时候就需要我们手动干预。

4.4.1 软件预取指令

x86下用 _mm_prefetch，ARM下用 __builtin_prefetch：

#include <xmmintrin.h>

void process_data(int* data, int size) {
    for (int i = 0; i < size; i++) {
        // 提前预取后面第4个元素
        _mm_prefetch(&data[i + 4], _MM_HINT_T0);
        
        // 处理当前元素
        data[i] = data[i] * 2 + 1;
    }
}

4.4.2 链表遍历的预取优化

链表是缓存的大敌。每个节点在内存里乱跳，硬件预取器根本猜不到下一个在哪。这时候可以手动预取：

struct node {
    int data;
    struct node* next;
};

void traverse_with_prefetch(struct node* head) {
    struct node* current = head;
    struct node* prefetch = head;
    
    // 提前预取后面第3个节点
    for (int i = 0; i < 3 && prefetch; i++) {
        prefetch = prefetch->next;
    }
    
    while (current) {
        // 预取更后面的节点
        if (prefetch) {
            __builtin_prefetch(prefetch->data);
            prefetch = prefetch->next;
        }
        
        // 处理当前节点
        process(current->data);
        current = current->next;
    }
}

4.5 L3缓存优化：跨核心共享的学问

L3是所有核心共享的，所以优化思路和L1/L2不太一样。核心问题是：如何减少跨核心的缓存一致性开销。

4.5.1 避免伪共享

前面提过伪共享，这里再强调一下。两个核心各自修改不同变量，但这两个变量在同一个缓存行里，就会导致缓存行在两个核心之间来回弹跳。

// 伪共享的典型场景
int counter[8];  // 8个线程各自更新自己的计数器

// 解决方案：每个计数器独占一个缓存行
int __attribute__((aligned(64))) counter[8];

4.5.2 数据分区

如果可能，让每个核心只访问自己的数据分区。比如多线程哈希表，可以给每个线程分配独立的桶段，减少L3上的竞争。

4.6 实战调优步骤

说了这么多，具体怎么上手？我建议按这个顺序来：

1. 先测量：用perf stat或vtune看L1/L2/L3的缺失率。如果L1缺失率超过10%，值得优化。
2. 检查数据布局：热点字段是否集中？结构体是否对齐？
3. 检查访问模式：是顺序访问还是随机跳转？能不能改成顺序？
4. 尝试预取：对不规则访问模式加软件预取。
5. 验证效果：每次改动后重新测量，别凭感觉。

好了，这一章就到这里。下一章我们会聊指令级并行优化，包括循环展开和SIMD向量化。到时候见。