21、内存池与缓存一致性：Cache Line对齐、预取(Prefetch)指令、写合并(Write Combining)

各位同学，今天我们来聊一个真正让内存分配器从「能用」变成「高性能」的关键话题——缓存一致性。

说实话，很多人在写内存池的时候，只关注了分配和释放的速度，忽略了CPU缓存这个「隐形杀手」。你想想看，你的分配器再快，如果数据在缓存里频繁miss，性能照样拉胯。我在几年前优化一个高频交易中间件时，就吃过这个亏。当时分配器已经做到纳秒级了，但整体吞吐就是上不去。后来用perf一分析，发现L1缓存miss率高达30%。嗯，问题就出在缓存一致性上。

为什么内存池要关心Cache Line？

先讲个基础概念。CPU不是直接从内存读数据的，它通过三级缓存（L1/L2/L3）来搬运数据。每次搬运的最小单位，就是Cache Line。在x86上，一般是64字节。

这意味着什么？

你哪怕只读一个4字节的int，CPU也会把相邻的64字节全部拉进缓存。反过来，如果你写了一个字节，整个Cache Line都会被标记为「脏」，需要回写。

所以，内存池里如果两个线程频繁操作同一个Cache Line里的不同对象，就会发生伪共享（False Sharing）。这是性能杀手，没有之一。

Cache Line对齐：实战做法

我个人习惯在定义内存池的元数据时，强制对齐到64字节。C11和C++11都提供了alignas，老项目可以用编译器属性。

// 内存池的每个空闲块头部
typedef struct alignas(64) pool_block_header {
    struct pool_block_header *next;   // 8字节
    uint32_t                magic;    // 4字节
    uint32_t                pad;      // 填充到64字节
} pool_block_header_t;

你看，这个结构体只有12字节的有效数据，但我强制它占满64字节。浪费吗？确实浪费。但换来的是：不同线程操作不同block时，绝对不会踩到同一个Cache Line。

我曾经在一个多线程日志库中，因为没做这个对齐，导致8个线程抢同一个Cache Line，性能直接腰斩。加上对齐后，吞吐量翻了一倍多。

预取指令：让数据「提前就位」

内存池里经常要遍历空闲链表。链表在内存里是离散的，每次访问下一个节点，大概率是Cache Miss。这时候，预取指令就派上用场了。

x86上最常用的是_mm_prefetch，或者直接内联汇编PREFETCHT0。它的作用很简单：告诉CPU，我马上要用这个地址的数据，你先把它拉到缓存里来。

// 遍历空闲链表时，提前预取下一个节点
static inline void* pool_alloc(pool_t *pool) {
    pool_block_header_t *block = pool->free_list;
    if (!block) return NULL;

    // 预取下一个节点到L1缓存
    _mm_prefetch((const char*)block->next, _MM_HINT_T0);

    pool->free_list = block->next;
    return (void*)(block + 1);
}

这里要注意：预取不是魔法。如果你预取得太早，数据可能被踢出缓存；预取得太晚，CPU已经 stalled 了。我个人经验是：在循环迭代中，预取「下一个」或「下两个」节点效果最好。

写合并：批量写入的加速器

写合并（Write Combining）是CPU的一种优化机制。当你连续写入多个地址时，CPU不会每次都写内存，而是先把这些写操作合并到一个写缓冲区（WC Buffer）里，等到缓冲区满了或者遇到屏障指令，再一次性刷出去。

这对内存池有什么意义？

如果你在分配内存后，紧接着要初始化这块内存（比如清零或填充模式字），连续写入同一Cache Line内的不同偏移，CPU会自动帮你合并写操作。但如果你跳着写，或者写不同Cache Line，合并就失效了。

// 好的写法：连续写入，触发写合并
void* ptr = pool_alloc(pool);
if (ptr) {
    // 假设对象前16字节是header
    ((uint64_t*)ptr)[0] = MAGIC_NUMBER;   // 偏移0
    ((uint64_t*)ptr)[1] = object_size;    // 偏移8
    // 这两个写操作在同一个Cache Line内，CPU会合并
}

// 坏的写法：跳着写，破坏写合并
void* ptr = pool_alloc(pool);
if (ptr) {
    ((uint64_t*)ptr)[0] = MAGIC_NUMBER;   // 偏移0
    ((uint64_t*)ptr)[8] = some_flag;      // 偏移64，下一个Cache Line
    // 两个不同的Cache Line，无法合并
}

你可能会问：这能差多少？我在一个网络包处理项目中实测过，利用写合并优化初始化流程后，批量分配+初始化的耗时减少了约40%。

知识体系总览

下面这张图总结了本章的核心逻辑：从内存池的分配路径出发，看缓存一致性如何影响每一步。

综合建议

在实际项目中，我建议你按这个优先级来优化：

1. 先做Cache Line对齐——这是基础，不做的话后面优化都白搭。特别是多线程场景，伪共享的杀伤力极大。
2. 再考虑预取——如果你的内存池遍历频繁（比如分配器内部链表操作），预取能带来10%-30%的提升。但要注意平台差异。
3. 最后优化写合并——这通常是在初始化或拷贝大块内存时才有明显效果。如果你的业务逻辑里写操作很少，可以跳过。

好了，这一章的内容就到这里。缓存一致性是个大话题，但抓住Cache Line对齐、预取、写合并这三个点，你的内存池性能就能上一个台阶。

---