自定义分配器性能对比：从对象池到线程缓存的全方位评测

从工程效率的角度讲，大多数时候我们根本不需要关心malloc背后做了什么——直到程序的时延曲线出现毛刺、内存占用翻了几倍，或者高并发下锁竞争让吞吐量直接腰斩。我早年做网络服务端的时候，对自定义分配器的态度都是“能用就行”，直到有一次压测发现，仅仅替换分配器就让单机QPS提升了接近三成，从那以后我就养成了一个习惯：凡是生命周期短、分配频繁、尺寸分布集中的模块，我都会认真做一次分配器层面的评估。这篇博文就围绕“自定义分配器性能对比”这个话题，讲讲我在实践中做过的方案选型、实现细节，以及一份可以复用的对比方法，希望对正在调优内存分配路径的同行有些参考价值。

1. 为什么要对分配器动手：先搞清楚默认分配器慢在哪

很多人一听到“自定义分配器”就觉得是造轮子、过度优化。但在动手写代码之前，我更建议大家先搞清楚一件事：系统自带的malloc/new到底在我们关注的场景里慢在什么地方。只有把根因找到了，你才知道该不该做优化、从哪个方向做。

1.1 通用分配器的三个隐藏代价

malloc是通用分配器，通用意味着它对所有类型的负载做折中。它对小对象分配会做内存池和缓存，对大对象会走mmap，同时要处理线程安全。这三件事都不便宜。

第一是管理开销。每次分配，分配器都要在堆上维护元数据：块的大小、使用状态、前后块的指针等。这些元数据通常直接放在分配块的头部或边界处，对小对象来说，元数据占比非常可观。比如你每次只申请16字节，但实际占用的堆空间可能是32字节甚至更多。这样不仅浪费内存，还会增加每次分配时遍历和维护链表的CPU开销。

第二是线程安全。标准分配器必须要处理多线程同时分配的情况。从最开始的全局锁，到后来的线程缓存（Thread Cache）、分区堆（Arena），虽然现代malloc实现已经有很精细的锁粒度，但在极端高并发下，分配热点依然会引发cacheline竞争。实测下来，多线程密集分配时，malloc在单核上的耗时往往比单线程高一个数量级，这个差距在很多性能敏感系统里直接决定了延迟走势。

第三是内存碎片。长时间运行的服务，不同大小的对象穿插分配和释放，堆很容易碎成一片一片。分配器会尝试合并相邻空闲块，但合并不是即时的，碎片一旦产生，分配器可能要遍历空闲链表查找合适的块，最坏情况是每次分配都走一次近似线性的扫描，时延自然就上去了。这也是为什么有些程序跑着跑着性能越来越差、重启以后又恢复的原因之一。

1.2 什么场景才值得做自定义分配器

搞清楚通用分配器的成本之后，我们还要明确：自定义分配器不是银弹，用错场景反而不划算。我总结了一下，适合自定义分配器的场景主要有这么几类：

• 分配频率极高且对象生命周期极短。比如网络请求的解析、消息队列的处理、游戏引擎每帧的临时对象，这些对象的存活时间往往只有几十微秒甚至更短，走通用分配器意味着频繁的锁竞争和元数据操作。
• 对象尺寸高度集中。比如你确定系统中只会分配256字节和1024字节两种块，那完全可以做两个固定大小的对象池，分配和释放都是O(1)操作。
• 需要批量回收。典型的如游戏场景的“关卡制”，把一整个场景的对象放在一个内存池里，场景销毁时一次性释放整块内存，完全不需要逐个释放。
• 对时延有严格上限。通用分配器在碎片化严重时会出现不可预测的长尾时延，而定制分配器可以通过结构设计把最大耗时控制在常数范围内。

如果需求都是长生命周期、尺寸差距很大的大对象，那自定义分配器带来的收益就非常有限，还得承担额外的复杂度和调试成本，我一般建议不要做。

1.3 自定义分配器到底要解决什么核心矛盾

本质上来讲，分配器的核心矛盾就两个：分配速度和内存使用效率。速度上，我们希望一次分配不经历系统调用、不碰锁、不做复杂遍历；效率上，我们希望内存池本身不要太大，避免浪费。

我之前做过一个对象池，一开始为了追求极致的分配速度，给每个线程预分配了很大的缓存空间，结果实测下来内存占用翻了三倍，被运维同学找上门来。从那以后我的习惯是：任何分配器改造都必须有内存维度的统计，不能只盯着分配耗时看。说实话，在内存不吃紧的机器上稍微浪费一点内存换速度没问题，一旦内存成为瓶颈，这种“速度幻觉”就会变成线上故障。

2. 分配器实现方案选型：从对象池到线程独享缓存

选型这件事没有标准答案，但有几个常见的实现方向，理解它们的适用边界和取舍，才能对后续的性能对比有个底。我也把几个方案的差异整理成了对照，方便按需选择。

2.1 固定大小对象池：最简单的常驻式分配

对象池的思路很好理解：预分配一大块内存，按固定大小切分成槽位，空闲槽位用链表串起来。分配时从链表头部弹出一个槽位，释放时把槽位塞回链表头部，两个操作都是O(1)。

这个方案适用于对象尺寸非常固定的场景。比如我在消息系统里给协议缓冲（protobuf）对象建过池子，每条消息对象的大小是编译期就确定的，用对象池非常合适。

实现的时候有个细节值得注意：空闲链表的指针存放在槽位内部，因为空闲槽位的“内容”用不上，存前一个空闲位置完全没问题。也就是说，堆内存本身既是存储对象的内存，又是空闲链表的载体，不再需要额外的空闲节点结构。这样能省掉一部分内存开销——虽然每个槽位里存一个指针（8字节）仍然算是额外开销，但比单独维护一个节点结构要省得多。

核心代码逻辑很简单：

c复制typedef struct objpool_block {
    size_t size;                   /* 槽位大小 */
    size_t capacity;               /* 槽位数量 */
    unsigned char* slots;          /* 槽位内存起始地址 */
    void* free_head;               /* 空闲链表的头指针 */
    struct objpool_block* next;    /* 用于挂多个内存块 */
} objpool_block;

void* objpool_alloc(objpool_block* pool) {
    if (pool->free_head == NULL) {
        return NULL;               /* 所有槽位用完 */
    }
    void* obj = pool->free_head;
    pool->free_head = *(void**)obj; /* 取下一个空闲槽位头指针 */
    return obj;
}

void objpool_free(objpool_block* pool, void* obj) {
    *(void**)obj = pool->free_head;
    pool->free_head = obj;
}

这里有个细节：*(void**)obj的意思是，把对象的起始位置当作一个指针来读写。因为对象在空闲时，槽位里的数据没有意义，这个位置用来存链表指针是安全的。但要注意，如果对象被分配出去后还没有释放，你不能对它做这个操作——那是未定义行为，也是这个方案的主要风险点。

对象池的缺陷在于对象尺寸必须严格一致。一旦混进不同尺寸的分配请求，就得到另一个方案：内存池。

2.2 分级内存池：通过分级降低内存浪费

分级内存池的思路是预先划分若干个尺寸等级（size class），例如16、32、64、128、256字节……分配请求到来时，取比请求大小大的最接近的等级来处理。这是很多高并发网络库和运行时系统采用的方案，本质上是拿一部分内存浪费来换速度。

关键在于如何选择size class的划分。划分太密，空闲链表多、管理复杂；划分太疏，内存浪费大。标准库通常用“对齐到2的幂”或者“按8字节倍数递增”，前者浪费率最高可达50%，后者对于小对象浪费率在8字节的范围内可接受。

我之前做过一个比较实用的分级方案：对64字节以下按16字节递增，64到256按32字节递增，256以上按64字节递增。这样小对象浪费率低，大对象浪费率也不会超过14%，整体内存使用效率在这个量级上还算均衡。

分配时，首先找到请求大小对应的size class索引，然后从该class的自由链表里取节点。如果链表空了，就一次性从大块内存里切出一批新节点。释放时，根据对象所属的size class和所在的块，把对象归还到对应链表。这个“索引定位”步骤如果用链表搜索会很慢，一般建议用数组存自由链表头，配合位运算计算索引，保持O(1)的定位成本。

2.3 线程独享缓存：解决锁竞争的关键

有了分级内存池以后，alloc和free已经是O(1)了，但多线程场景下，全局池的并发访问仍然会引发锁竞争。解决思路通常有两种：加细粒度的锁（比如按size class加锁），或者做线程局部缓存。

线程局部缓存的思路是：每个线程维护一组小型free list，称为Thread Cache。分配时优先从本线程缓存取，只有缓存空了才去全局池批量取；释放时优先归还到线程缓存，只有缓存满了才把一批节点还给全局池。这样大多数alloc/free完全在本地完成，全程无锁。

这个方向就是tcmalloc、jemalloc这类高性能分配器的核心思路。自己实现的时候不需要做到那么极致，只需要按需优化即可。我记得我第一次给一个多线程网络服务加线程缓存，压测数据显示分配热点上的锁竞争基本消失，吞吐量有了非常明显的提升。但也有一点要注意：线程缓存的节点来自全局池，释放的时候如果归还错线程，跨线程释放会导致缓存振荡，所以实现时要判断“对象到底属于哪个池”。最简单的方式是给每个块加归属标记，或者通过地址范围判断。

2.4 栈式分配器：生命周期嵌套时的高效异类

如果对象的生命周期是严格的“先分配的后释放”（LIFO），那栈式分配器几乎是零成本方案。它维护一个“顶指针”，分配只需要把顶指针往上挪，释放就是把顶指针往下挪，批量回退更简单，直接改指针就行。

这个方案特别适合在游戏引擎里做场景内对象管理，或者在一个请求处理函数的生命周期内管理临时缓冲区。缺点也显而易见：不支持随机顺序释放。如果某个对象要提前释放，你会立刻陷入麻烦，只能等它所在的那一批次全部结束再统一回退。使用之前一定要想清楚准入条件，否则后续扩展时会很痛苦。

2.5 方案选型对照：哪种适合你

为了更直观，我把上面说到的几种方案放在一起做个对照：

实际项目里，方案往往不是单一的。我在服务端和游戏项目里见过最多的是“分级内存池+线程缓存”组合，前者解决尺寸分布问题，后者解决并发竞争问题。对象池通常只用于某些特别热点的单一结构。

3. 性能对比的完整实操：一份可复现的评测方案

到了最核心的部分：如何科学地评估这些分配器到底快多少。我见过很多性能对比做得很随意，要么基准测试代码逻辑有缺陷，要么统计口径不统一，最终出来的数据完全没有参考价值。这里我分享一套我自己用的对比流程和方法，从环境准备到基准设计再到数据解读，一步步说清楚。

3.1 环境和被测对象约定

先约定一下基线。为了可复现，我建议所有测试在同一台机器、同一编译选项下进行，被测对象至少包含：

• 系统默认分配器 baseline：malloc/free（或者对应的new/delete）
• 固定对象池 objpool：尺寸固定、自由链表实现
• 分级内存池 sizepool：按size class分级，配合线程局部缓存
• 栈式分配器 marker（仅测试LIFO释放场景）

编译时统一使用-O2优化级别，开启-fno-strict-aliasing以避免潜在的严格别名问题。所有被测代码除分配器不同外，其余逻辑完全一致。

注意：具体数值会因机器和负载不同而差异很大，我这里给出的数据主要是用来表达相对比例和趋势，不要直接当成你机器的基准结果。

3.2 测试负载设计：单线程与多线程两套

为了让对比更有说服力，我设计了两个基准：

基准A：单线程连续分配/释放
循环100万次、每次分配一个128字节的块、写入数据后立即释放。这个模式模拟“每个对象只活一小会儿”的场景，考察分配器在无竞争条件下的基础开销。

基准B：多线程混合分配/释放
启动8个线程，每线程循环50万次、随机分配64到256字节的块、在一个随机延迟（模拟持有时间）后释放。这个模式模拟真实的高并发服务场景，考察分配器在高竞争条件下的表现。

每个配置跑5轮，取中位数。为什么不取平均值？因为平均值容易被少数极端值拉高，中位数更能反映典型时延。如果还想更严谨，可以同时记录P99/P999的时延分布数据。

3.3 测试实现：代码骨架与勘误细节

下面是一个简化版基准代码的骨架。为了控制篇幅，我只保留关键逻辑，完整版本你可以按这个思路自己扩充：

c复制#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>
#include <time.h>

#define ITERATIONS 1000000
#define OBJ_SIZE 128
#define THREAD_COUNT 8

/* 计时函数：返回纳秒 */
static double now_ns(void) {
    struct timespec ts;
    clock_gettime(CLOCK_MONOTONIC, &ts);
    return (double)ts.tv_sec * 1e9 + (double)ts.tv_nsec;
}

/* 测试单线程只干活 */
static void bench_single(void) {
    double t0 = now_ns();
    for (int i = 0; i < ITERATIONS; i++) {
        void* p = malloc(OBJ_SIZE);
        if (p) {
            /* 写入数据，防止编译器优化掉分配 */
            *(volatile char*)p = 1;
            free(p);
        }
    }
    double t1 = now_ns();
    double per_op = (t1 - t0) / ITERATIONS;
    printf("malloc single-thread: %.1f ns/op\n", per_op);
}

/* 线程参数 */
typedef struct {
    int thread_id;
    int iterations;
} thread_arg;

static void* thread_worker(void* arg) {
    thread_arg* ta = (thread_arg*)arg;
    /* 随机种子按线程区分 */
    unsigned seed = ta->thread_id * 12345 + 12345;
    for (int i = 0; i < ta->iterations; i++) {
        size_t sz = 64 + rand_r(&seed) % 193; /* 64~256字节随机 */
        void* p = malloc(sz);
        if (p) {
            *(volatile char*)p = 1;
            free(p);
        }
    }
    return NULL;
}

static void bench_multi(void) {
    pthread_t th[THREAD_COUNT];
    thread_arg args[THREAD_COUNT];
    double t0 = now_ns();
    for (int i = 0; i < THREAD_COUNT; i++) {
        args[i].thread_id = i;
        args[i].iterations = ITERATIONS / THREAD_COUNT;
        pthread_create(&th[i], NULL, thread_worker, &args[i]);
    }
    for (int i = 0; i < THREAD_COUNT; i++) {
        pthread_join(th[i], NULL);
    }
    double t1 = now_ns();
    double per_op = (t1 - t0) / ITERATIONS;
    printf("malloc multi-thread: %.1f ns/op\n", per_op);
}

int main(void) {
    bench_single();
    bench_multi();
    return 0;
}

有几个坑我踩过，值得重点提一下：

第一，用volatile char写入数据，是为了防止编译器自动优化掉没有“副作用”的分配和释放。如果只分配不写入，-O2的优化器很可能直接消掉整个循环，你还以为是0ns，其实是空的。

第二，计时用clock_gettime(CLOCK_MONOTONIC)而不是gettimeofday。前者是单调时钟，不受系统时间调整的影响，做性能测试会更可靠。

第三，多线程的随机数生成用了rand_r而不是rand，后者在多线程下需要加锁保护，会把性能结果搅乱。

3.4 关键参数计算与实现细节：示例对象池代码

为了让对比更完善，我再用固定大小对象池作为样例，把实现和参数计算方法都拆开讲。假设我们需要一个服务，每次请求请求体大小平均80字节，为了安全取最大128字节，那么槽位大小可以定为128字节。

第一层计算是内存块大小。假设我们预分配1024个槽位：

code复制槽位大小 = 128字节
槽位数量 = 1024
内存块总大小 = 128 * 1024 = 131072 字节 = 128 KB

如果内存块对应4KB内存页，也就是32个虚拟内存页。内存占用可接受。

第二层计算是池子最大对象数。为了不让池子无限增长，通常会在池子里维护两个链表：空闲链表和已分配链表。当已分配数量达到上限时，分配返回NULL或者触发扩容。这个上限建议控制在一个合理的峰值请求并发量的两到三倍之间。

下面是一段简化但可运行的实现，关键点在注释里：

c复制#include <stdlib.h>
#include <string.h>
#include <stdio.h>

#define SLOT_SIZE 128
#define SLOT_COUNT 1024

typedef struct objpool {
    unsigned char memory[SLOT_SIZE * SLOT_COUNT];
    void* free_head;               /* 空闲链表头 */
    int used_count;
} objpool;

void objpool_init(objpool* pool) {
    pool->free_head = NULL;
    pool->used_count = 0;
    /* 将所有空闲槽位串成链表 */
    for (int i = 0; i < SLOT_COUNT; i++) {
        void* slot = (void*)&pool->memory[i * SLOT_SIZE];
        *(void**)slot = pool->free_head;
        pool->free_head = slot;
    }
}

void* objpool_alloc(objpool* pool) {
    if (pool->free_head == NULL) return NULL;
    void* obj = pool->free_head;
    pool->free_head = *(void**)obj;
    pool->used_count++;
    return obj;
}

void objpool_free(objpool* pool, void* obj) {
    if (obj == NULL) return;
    *(void**)obj = pool->free_head;
    pool->free_head = obj;
    pool->used_count--;
}

int main(void) {
    objpool pool;
    objpool_init(&pool);
    void* p = objpool_alloc(&pool);
    if (p) {
        memset(p, 0, SLOT_SIZE);
        printf("allocated at %p, used=%d\n", p, pool.used_count);
        objpool_free(&pool, p);
        printf("freed, used=%d\n", pool.used_count);
    }
    return 0;
}

这里关键的一步是第12行：void* slot = (void*)&pool->memory[i * SLOT_SIZE]; *(void**)slot = pool->free_head;。它把每个槽位的开头8字节当成一个指针，存放上一个空闲槽位的地址。这样内存中既存储了对象，又在空闲时存储了链表指针，不需要额外的链表节点结构。

但有两点必须要告诫自己：

• 槽位大小必须不小于sizeof(void*)（通常是8字节），否则空闲链表指针无处可存。
• 如果槽位被分配出去后，使用者往里面写数据，就可能覆盖了空闲链表指针——但这是安全的，因为使用者写入数据时这个槽位已经不属于空闲链表了，只有归还后才能重新进入链表。前提是使用者不能越界写入。

3.5 实验结果：数值与解读

在一台8核物理机（Intel Xeon、2.9GHz、64GB内存）上，我用上述方法跑了一组数据。为了让你对量级有体感，我把结果放在表格里：

从数据里能看出几个现象：

单线程下，对象池6.7倍左右的加速，主要来自去掉了元数据管理和链表遍历。malloc需要维护空闲块结构，做完边界检查后才能分配，而对象池只是从一个链表头弹节点，操作本身就是几条指针赋值。差异自然大。

多线程下差异更大。malloc在8线程竞争时耗时从32.5ns涨到210ns，翻了超过6倍，原因是全局锁和缓存行争抢。而固定对象池由于测试是单池并发，理论上也应该有竞争，但实测中它也能保持较低耗时，因为对象池的free list操作指令很少，锁竞争窗口极短。当然，如果没有加锁，这本身是不安全的——我在这组数据里用的是加锁实现，只是临界区极短。

线程缓存的分级池在多线程场景下降到了11ns左右，和对象池接近。它的核心优势在于，绝大多数分配和释放都发生在线程局部缓存里，不碰全局池的锁，跨线程竞争被显著抑制。

3.6 性能对比的公平性陷阱

做对比的时候有几个坑尤其容易误导结论。

第一，释放时应与分配走同一路径。对比对象池时，如果你分配走对象池、释放走系统free，等于把对象池的释放优势忽略掉，结果肯定不公平。所以所有路径要统一：分配、释放都用被测分配器提供的方法。

第二，对象生命周期分布要贴近真实负载。如果一个对象的存活时间很长（远大于测试循环周期），或者非常不均匀，那测试结果和真实使用场景会差很多。建议在基准里加入“持有时间”的随机延迟，而不是分配后立刻释放。

第三，防止编译器过度优化。如果不写入数据，或者不把分配结果透传给外部函数，优化器可能在-O2下把整个分配/释放逻辑删除。建议用volatile写入、或者把指针传给一个不会内联的外部函数，来确保分配真的发生。

第四，线程数要匹配实际部署。压测线程数太少看不出竞争影响，太多又可能因为调度开销掩盖分配器本身的差异。建议至少跑一个和核心数相近的线程数。

3.7 从数据到决策：什么场景收益最大

基于上面的测试方法，我可以给出一个更通用的判断框架。

如果对象尺寸集中在几百字节以内、生命周短暂且分配频繁，那么分级内存池或线程缓存方案基本能拿到5到30倍左右的提升。如果对象尺寸非常单一，固定对象池可能更简单也更快。如果对象生命周期有严格的嵌套关系，栈式分配器零成本的优势完全值得优先使用。

反过来，如果对象大小很大（超过几百KB）、生命周期很长、释放顺序完全随机，那么自定义分配器的复杂度就高于收益，直接用系统分配器可能更合适。

4. 自定义分配器开发中的常见问题与排查技巧

写完自定义分配器不代表万事大吉，我刚才差点踩进去的队列就是“代码能跑”和“代码真的对”之间的距离。这节专门梳理开发、集成和性能排查中常见的问题，以及对应的解决办法。

4.1 问题速查表

4.2 定位越界写：canary值和ASan配合

自定义分配器里最常见又最难查的bug就是越界写。一个对象分配了128字节，结果往里面写了129字节，程序员往往发现的时候已经是几个小时后的事，堆已经被写坏。

我的做法是在对象池里给每个槽位的前后各留4到8字节的canary区域，初始化为固定值，比如0xCD。每次分配和释放时检查canary有没有被改动。如果改动，就说明发生了越界写，甚至能帮你定位到具体池子和槽位。这个方法开销很低（8字节的检查），但能救回不少调试时间。

另外，开发阶段一定要用AddressSanitizer（-fsanitize=address）跑一遍单测。它会对所有内存操作做插桩，越界、double-free、释放后使用都能直接捕获。虽然ASan会显著降低性能，但它只在开发阶段启用，不进入生产。

4.3 识别伪共享和线程间竞争

多线程下自定义分配器性能差，很多时候不是分配算法慢，而是缓存行竞争（伪共享）。例如，两个线程各自维护一个free list的计数器和头指针，如果这两个变量位于同一个缓存行，即使它们逻辑上完全独立，每次修改都会导致整条缓存行在两个CPU核心之间来回同步。

我排查过的一个案例很典型：一个分级内存池的free list头指针数组，相邻两个size class的头指针恰好落在同一个缓存行里，高并发下两个线程分别操作不同size class的列表，结果性能比单线程还差。解决办法很简单：给每个free list头加padding，让它们分布在不同的缓存行。`

在数据结构设计上，我会建议每个线程的局部数据放在独立的、以64字节对齐的结构体里。这样每个线程操作的都是自己私有的缓存行，彻底消除伪共享。

4.4 跨线程释放的正确姿势

跨线程释放是自定义分配器的一个难点，也是高频事故点。比如线程A分配了一个对象，处理完以后交给线程B回收。如果你用的是线程局部缓存，对象从B的本地缓存归还，但对象实际是从A线程的缓存拿的，这会导致归属混乱。

我的处理方式有三种，视场景选：

• 禁用跨线程释放：在分配器API上明确禁止，或从代码结构上保证对象不跨线程回收。
• 对所有对象标记归属池：释放时通过地址范围查找它属于哪个全局池，然后归还到全局池，而不是线程局部缓存。
• 使用线程序号+全局池的组合方案：跨线程释放时直接归还全局池，由全局池来做后续分发。

从工程角度，我优先推荐第三种，这样跨线程释放可以工作，同时常规场景仍能享受线程缓存带来的收益。

4.5 调试技巧：统计打点与可视化

正常开发阶段，我会在分配器内部埋几个计数器：分配次数、释放次数、池中总节点数、空闲节点数、高峰已用节点数。这些指标对定位内存泄漏非常有用。比如你发现某段运行后“总节点数”持续增长而“空闲节点数”始终不变，说明分配了一个对象但没有放回，或者free链表断链了。

有些项目里，我还会加一个定期扫描函数，把池的全部槽位状态输出为文本或写入日志。这虽然不能直接定位bug，但能让你直观看到空闲链表是不是出现了环、槽位的分配顺序是不是符合预期，是排查复杂内存问题的利器。

5. 经验盘点：自定义分配器的落地建议

最后按照我自己的使用经验，给几个实用的落地建议，这些并不适合所有项目，只是在多次实践后我认为比较可靠的判断路径。

第一个建议是先测量再动手。在写任何自定义分配器之前，先用perf、valgrind或者简单的计时函数定位一下，你当前的系统里分配器到底占了多少CPU时间。我见过有人在代码里用分配器替换了全局new，结果性能提升不到2%，回头一查发现分配只占整个流程的1%时间。这种优化纯属自嗨。

第二个建议是越小越好。能把分配器限定在一个模块甚至一个类里，尽量不要全局替换。这既是为了降低引用计数和维护成本，也是为了把bug隔离在局部。全局替换分配器往往是大型内存灾难的开端。

第三个建议是内存统计必须做。如果你做优化后没有记录池子的内存使用率，那等于闭着眼睛开车。我给自定义分配器定的标准是：至少记录“总分配内存”“已使用内存”“空闲链表节点数”“池扩展次数”这四个指标。上线前跑一轮压测，把所有指标记录下来，后续改代码时对照这些数据，才能判断是变好了还是变坏了。

第四个建议是不要过早把简单方案改成复杂方案。固定对象池能解决的问题，就不要上分级加线程缓存。很多情况下，最简单的对象池已经够用，额外的复杂度只是让你在以后排障时更头痛。

以我个人的经验，分配器优化真正的作用不是让某个单独的函数变快，而是降低整个系统的时延波动和锁竞争。那些被优化掉的microseconds，在高并发放大后往往变成了用户可感知的延迟下降。所以这个领域虽然老，但依然值得投入。如果你正打算做类似改造，不妨先从这组对比方法和对象池代码入手，在一块局部业务上试验，八九成的把握能拿到可量化的收益。

最后再分享一个小技巧：换分配器后，先跑一遍功能单测，再跑一遍性能压测，最后再看内存曲线。三条线都稳了，再考虑全量合并到主分支。这条顺序帮我避过不少夜里的紧急回滚。