自定义内存分配器实战：从malloc瓶颈到性能提升30%的完整方案

写这篇主要是因为去年调优一个网关服务时被默认内存分配扎扎实实地上了一课。业务线程一多，perf top 里 malloc/free 相关符号占比直接冲进前三，P99 延迟的毛刺十有八九都指向分配器内部。后来我把服务里的核心热路径切换成自定义分配器，整体吞吐提升了接近 30%。这篇文章就把我当时的完整思路、自己动手做的性能对比过程，以及那些文档里不太会写的坑一次性讲清楚。如果你也在纠结“要不要自己写分配器”或者“写哪种分配器”，这篇应该能帮你省掉不少弯路。

1. 默认分配器的性能瓶颈：只有先搞清楚慢在哪，才知道要不要自己写

有人一听说“自定义分配器”就觉得是炫技，觉得 malloc 是 C 标准库钦定的东西还能慢到哪去。但真实业务场景里，它确实是明确的热点。要理解自定义分配器为什么能赢，得先拆清楚默认分配器把时间花在哪儿了。

1.1 从 malloc 到 ptmalloc：一次分配到底经历了什么

我默认以 Linux 下的 glibc malloc 为例，它是 ptmalloc2 的衍生实现。绝大多数人写的服务都跑在它上面，你遇到的行为基本都来自它的设计取舍。

当你第一次调用 malloc(24) 时，分配器会向操作系统申请一大块连续内存，通常是 mmap 或 brk 方式拿到 128KB 甚至更大的内存块，然后在用户态把这块内存切成各种大小的 chunk。每个 chunk 头部会存 prev_size 和 size 两个字段，size 里还要塞进三个标志位，所以一个空闲 chunk 至少额外消耗 16 字节的元数据。这还没算 malloc_usable_size 这类对齐要求带来的填充。

请求释放时，free 会把 chunk 放回对应的 bin 里。对于小内存，ptmalloc 有 fastbins，释放后不会立刻合并，下次相同大小请求能直接从 fastbin 取，这一段路径其实很快。可一旦涉及多线程，事情就变了：ptmalloc 的 arena 机制会让每个线程尝试在自己的 arena 里分配，但 arena 数量有限（默认和核数相关），线程一多必然产生共享与锁竞争。当 fastbin 不满足条件或需要从 top chunk 切割时，还需要锁住整个 arena 的操作。分配时间从几十纳秒直接跳到几百纳秒甚至更高。

所以可以用一句话概括默认分配器的代价：通用性强，但每条通用路径后面都挂着状态管理和并发控制。你的程序如果用不到它的通用性，就等于在为别人的需求买单。

1.2 性能损耗的构成：不只是锁，还有缓存和碎片

我在做优化前把问题切成四个维度来看，这样后面对比自定义分配器时才知道观察哪些指标。

第一是锁竞争。多线程高频 malloc/free 时，arena 锁和 bin 锁都会形成真实的串行化。线程从 4 个涨到 16 个，吞吐未必翻四倍，因为大家都在抢同一把锁，缓存行还在各个核心之间 bouncing。第二是系统调用。虽然 ptmalloc 会缓存空闲内存，但内存块释放后如果触发 trim 或大块分配走到 mmap 路径，就会直接切内核态，一次就是微秒级损耗。第三是内存碎片。长时间运行后，分配器很难找到连续的合适空闲块，不得不频繁做合并或重新请求，表面上看是内存问题，最终反馈到 CPU 上的成本也不小。第四是缓存局部性。默认分配器分配出的对象在地址空间里可能是跳着走的，你 new 一串对象再遍历时，每次都会缓存未命中，这个成本甚至比分配本身还高。

这四个维度不是我猜的，是压测时候逐个对比验证过的。特别是锁竞争和缓存局部性这两个，在真实业务里往往比分配动作本身更致命。自定义分配器之所以有效，本质是砍掉了这些“通用性税”。

2. 四类自定义分配器：原理、实现要点和适用边界

自定义分配器不是一个东西，是一族东西。我实际动手实现并测过的有四类：固定大小内存池、Arena/栈式分配器、空闲链表分配器和线程本地缓存分配器。它们的适用场景差异很大，别指望一个大而全的分配器解决所有问题。

2.1 固定大小内存池：为同构小对象而生的极速方案

这是最简单也最容易无脑提速的一类。如果程序里反复分配和释放相同大小（或者几种固定大小）的对象，完全可以让内存池提前切好一批固定槽位，分配时直接取一个空闲槽，释放时把槽放回去。

我自己的实现是用一个数组保存所有槽位，另外维护一个空闲栈。分配就是：从栈顶弹出一个索引，返回对应地址。释放就是：把这个索引压回栈。整个操作只有一次数组访问加一次入栈，连 CAS 都可以不用（单线程场景）。更激进的做法是把空闲槽本身组织成单向链表，空闲槽的第一个字存下一个空闲槽地址，这样连索引数组都可以省掉。

多线程下，这个设计要加锁保护空闲链表。好在临界区极短，加锁后依然比 ptmalloc 快很多。它的硬伤是对齐和大小选择：如果对象大小是 40 字节，槽位往往会按 48 或 64 对齐，浪费率就能到 20% 以上。内存池只对“小而均匀”的对象划算，盲目套到大块内存上就没什么意义了。

2.2 Arena/栈式分配器：一揽子分配、一次清空的场景利器

这种分配器在游戏引擎和请求处理模型里非常流行。它一次性向系统申请大块内存，然后内部用一个指针记录当前分配位置。每次分配只需要检查剩余空间，然后移动指针返回地址，开销就是几个指令。

释放操作通常也简单粗暴：它不和 malloc 那样支持任意位置释放，而是整体重置。很多实现直接提供 reset() 把游标拨回起点。应用层遵守“这批对象生命周期一致，最后统一清空”的规矩，就能拿到逆天的分配速度和几乎为零的释放成本。

我们网关服务里每个请求的处理链就非常适合 Arena。请求来了按需分配各种临时结构，请求结束一次 reset，内存整块回收。唯一的风险是如果有些对象生命周期比 Arena 长，比如要异步处理或塞进队列，就会产生悬垂指针。我在代码规约里明确禁止把 Arena 内存的对象放进跨线程队列，宁可拷贝一份也不能图快。

2.3 空闲链表分配器：处理大小混杂的中间态

如果对象大小从 8 字节到 4KB 都有，但比例相对固定，固定大小池和 Arena 就不够用了。此时可以按常见大小分类，比如 8、16、32、64、128、256、512、1024、2048、4096，每种大小维护一条空闲链表，也就是 segregated free list。

分配时把请求大小向上取整到对应档位，从该档链表取一块；如果链空，就向底层系统申请一个大块，切成若干同尺寸块挂进链表。释放时按地址判断属于哪个大块、对应哪个档位，再插回链表。为了快速定位块属于哪个池子，通常需要一个注册表或按大块地址范围做二分查找。

这种设计单独用其实有点鸡肋，因为和通用分配器的思想有重叠，元数据管理也麻烦。但把它作为某个模块的专用路径，或者和池子组合成二级结构时，效果不错。比如我们日志系统里变长消息的分配就是这种分配器，比直接 malloc 减少了约三分之一的小块分配延迟。

2.4 线程本地缓存：从根上消灭锁竞争

最后一种思路不是减少分配，而是把分配完全变成线程私有。每个线程维护一个独立的小块缓存池，分配时优先从线程自己的池子里取，完全不需要和别的线程争锁。只有池子不够时才到公共区批量搬一批出来。

这种就是 tcmalloc 的核心思路。我自己做了一个轻量版本：线程本地用 thread_local 变量维护一个简单的内存块链表，批量从全局池搬运。实测单次小对象分配大概稳定在 20 到 40 纳秒，多线程下几乎没有可见的锁竞争退化。

它的代价是线程数量和内存占用挂钩。每个线程的缓存越多，整体闲置内存越高；线程频繁创建销毁时还会导致池子与线程生命周期耦合，带来内存迁移和回收问题。服务器里如果线程池是固定的，这种分配器就是“无脑爽”的选择。如果线程经常动态创建，要额外实现线程退出时的内存归还逻辑，复杂度立刻上来。

我常给朋友们做的一个对比表格是这样的，可以直接帮你对症下药：

3. 测试方法和负载设计：做不好这步，对比结果全是噪声

老实说，分配器性能对比里最容易翻车的不是分配器本身，而是测试方法。我第一轮测试结果就出过笑话：某个实现可能因为优化器把 allocate 循环整个删了，测出来是 0 纳秒，我当时差点以为自己发明了永动机。所以要先把基准实验设计得足够“防作弊”。

3.1 统一接口封装：公平对比的前提

直接比较裸 malloc 和自写分配器的 API 并不公平，因为调用约定、错误处理这些都可能存在差异。我用 C++17 的 std::pmr::memory_resource 做了一层统一适配，四种分配器都实现成独立类，暴露一致的 allocate/deallocate 接口。测试代码只面向接口，不关心底下是谁。

用 pmr 的好处还有一点：标准库容器可以无缝接入。std::pmr::vector<T> 可以直接走我写的 memory_resource，这比全部用裸指针手动管理要贴近真实工程。在真实项目里，你大概率也会走这条路，而不是把所有容器都改成手工 allocate。

下面是一个简化版的接口示意，强调“同一语义下做切换”：

cpp复制class allocator_interface {
public:
    virtual ~allocator_interface() = default;
    virtual void* allocate(size_t bytes) = 0;
    virtual void deallocate(void* p, size_t bytes) = 0;
    virtual void release_all() {}
};

class default_malloc_allocator final : public allocator_interface {
public:
    void* allocate(size_t bytes) override { return ::malloc(bytes); }
    void deallocate(void* p, size_t) override { ::free(p); }
};

真正的内存池、Arena 版本都是这个接口的实现，测试只有一行差异：创建哪个对象。这样就杜绝了“各写各的接口导致调法不同”这类不公平因素。

3.2 构造能反映真实业务的负载模式

分配器在不同负载下的表现可能是两个极端，只用一种负载下结论纯属自欺。我设计了四种负载模式：

模式 A 是批次分配再批次释放。模拟服务器每处理一个请求就创建一组临时对象，请求结束统一销毁。每个批次分配 20 个 64 字节对象，批次之间做少量计算，然后把整批释放。

模式 B 是高频随机分配和释放。每个线程维护一个 64 容量的活跃集合，随机插删，模拟缓存类场景。对象大小固定 128 字节，但释放顺序完全随机。

模式 C 是大小混合流。分配大小从 16 字节到 4KB 按 Zipf 分布生成，活跃数量不固定，用来暴露碎片和分档的差异。

模式 D 是多线程混合模式。8 个线程同时跑模式 B，但所有线程共享同一个用于分配的对象集合，制造真实锁竞争。

这四种模式分别对应真实系统里最常见的请求处理、缓存驱逐、消息队列和共享数据结构场景。跑完一轮我才敢说哪个分配器在什么场景下更好。

3.3 防止优化器“搬走”你的分配热点

这是基准测试最重要的一环。分配器返回的指针如果最终没有被使用，优化器完全可能依据 as-if 规则把分配优化掉。比如循环里 malloc 后立刻 free，gcc 会识别出这个模式并直接把分配删除。所以必须让编译器“相信”分配结果逃逸了，但运行时不能产生无法消化的开销。

我采用的惯用做法是在循环结束后用一个黑盒函数处理分配结果，黑盒内部做累加操作，加到外部变量上。这样分配器必须真实工作，又不会在热路径里塞入无用代码。

cpp复制__attribute__((noinline))
static void escape_sink(void* p) {
    asm volatile("" : : "r"(p) : "memory");
}

每轮迭代里，分配完调用 escape_sink 让指针逃逸，释放完成后也做一次逃逸屏障。这个方法虽然粗糙，但真实有效。类库版的 benchmark 里普遍提供 DoNotOptimize，如果你用 Google Benchmark 直接调那个函数就行。

3.4 统计口径：平均延迟会骗人，看 P50 和 P99

分配器的延迟分布非常不均匀。默认分配器平时几纳秒，一旦触发系统调用或锁等待就是几百纳秒，平均值看起来不痛不痒，但尾延迟早就把上层服务的 P99 拖崩了。所以我每一轮测试都记录单次 alloc+dealloc 的耗时，统计 P50、P90、P99 和 MAX。

测试环境我固定在同一台机器上跑三遍取中位数：CPU 关闭睿频，绑核运行，进程独占。这样最大限度降低 CPU 频率抖动和调度噪声带来的误差。每轮测试预热 10 万次后，再正式测 1000 万次。

跑一遍下来我就知道，单纯看平均值做决策是懒惰的。真实优化目标永远是查 P99 和 MAX，这两个指标能直接告诉你，当线上流量顶上来的时候，分配器会不会成为那根压垮骆驼的稻草。

4. 实测结果：快在哪，也慢在哪

这节给出的数字全部来自我自己的测试环境：Intel Xeon 5120 的机器，Ubuntu 20.04，glibc 2.31，gcc 9.3，编译选项 -O2 -std=c++17。写在这里不是为了让你背书，而是方便你自己复跑时有个量级参考。分配器测试对平台太敏感了，换个 glibc 或者换成 jemalloc 做对照，比例会变但趋势通常稳定。

4.1 单线程批次场景：Arena 是当之无愧的王者

先看模式 A 的结果，也就是“整批分配整批释放”的请求级场景：

这个结果在意料之中。Arena 的分配就是移动一个指针，释放整批就是一次 reset，一次请求内 20 个对象时它简直是无敌的。固定大小池也很快，但每次 release_all 需要遍历槽位回收到空闲链，这部分比 Arena 的指针拨回去了成本更高。malloc 的成绩不差，P99 却到了 800 多纳秒，说明偶发的空闲块合并和锁路径给它拖了后腿。

我之前提到过 cache locality 的影响，这里也顺带验证了：用 Arena 分配的一批对象，在内存里往往连续分布，遍历这批对象时缓存命中率明显提升。虽然这没直接体现在分配器耗时的统计里，但包含完整业务循环后，整个处理链路的耗时改善往往比单独看分配器更夸张。

4.2 高频随机释放：内存池开始拉开差距

模式 B 中每个线程随机插删固定大小对象，这种操作是内存池的舒适区，因为释放就是入栈，没有 bin 合并，没有碎片整理。

固定大小池在这个场景下平均快了接近 4.7 倍，P99 差距更大。反直觉的地方在于它的内存占用反而比 malloc 高了 40% 左右，因为槽位没有按需归还给系统。这块多出来的内存，就是换取速度的显性成本。如果你的服务内存余量本来就紧张，这个 trade-off 得提前算清楚。

随机释放场景对默认分配器最不友好的一点是碎片化。malloc 在这种模式下需要频繁检查相邻块并做合并，每次 free 都可能触发链表遍历，延迟方差因此变得很大。固定大小池则没有合并的概念，天然规避了这个问题。

4.3 多线程共享竞争：比例差距最大的场景

模式 D 是 8 个线程共享活跃集合，同时高频分配和释放对象。这个场景下，glibc malloc 的锁竞争被彻底激发：

线程数涨上来后，glibc malloc 的 P99 直接飙到将近 6 微秒，这对大部分线上系统都是不可接受的毛刺水平。固定大小池即使加了锁，因为临界区极短，表现也远超 malloc。线程本地缓存最亮眼，平均延迟只有 malloc 的八分之一，P99 更是低了两个数量级。

看到这个结果时我把测试代码又核了一遍，确认共享活跃集合让每个线程的释放对象能被别的线程分配，也就是存在真实跨线程交接。这种场景下线程本地缓存能赢，原因不是缓存本身快，而是它把 malloc 里那 90% 的锁开销直接从路径上删掉了。线程本地缓存看起来最慢的瞬间反而是缓存 miss 后到全局池搬内存块的时候，那个操作偶尔会到几百纳秒，但从统计上看完全在可控范围内。

4.4 大块内存与生命周期极端情况：自定义分配器并非无所不能

我也测试了大块内存场景，对象大小超过 1MB。这个量级下所有分配器都绕不开 mmap 系统调用。自定义分配器如果内部还保留这些大块不归还，内存峰值会非常难看；如果每次也走系统调用，那和 malloc 就没本质区别，甚至因为多一层封装更慢。所以我的结论是：巨块内存别用自定义分配器，直接交还给系统就好。

另外还有一个比较极端的生命周期测试：分配 20 万个 256 字节对象，然后只释放其中 99% 的对象，剩余 1% 长期存活，整个过程重复 10 轮。这种模式下，固定大小池的槽位被那存活对象长期占着，新对象不断把池子撑大，最终内存占用比 malloc 翻了 3 倍以上。这不是 bug，是槽位模型的天然缺陷——它无法整理已死但未释放位置的内存。真实系统里如果存在“少量对象长时间存活”的模式，固定大小池得配合定期重建才能用。

5. 性能之外容易踩的坑：我在真实项目中交过的学费

只看快慢，自定义分配器看似稳赢，实际上工程落地的过程中，我踩过不少文档不会告诉你的坑。有些坑是性能问题，有些干脆是正确性问题，比性能问题更可怕。

5.1 对齐问题：你以为 8 字节对齐就万事大吉，SIMD 代码可不答应

系统 malloc 返回的地址满足 max_align_t，也就是 16 字节对齐，这个我从来不用操心。换成自定义分配器后，如果只是 (char*)pool + offset 这样切块，offset 没有按任何对齐规则排过，地址就可能变成 12 字节对齐甚至更低。普通负载下压根察觉不到问题，一旦代码里有 AVX 指令读写 32 字节对齐的数据，直接 SIGSEGV。

更隐蔽的是 C++17 里 aligned operator new 的语义。有些容器或库会调用 operator new(size, align_val_t{64}) 来请求 64 字节对齐。如果你的自定义分配器无视这个对齐参数，照样返回 16 字节对齐的地址，表面不会崩，但某些编译器会为它生成 vzeroupper 等指令，性能掉得莫名其妙。

所以分配器的对齐规则要写好，常见做法是每个分配请求都向上对齐到 16 或 32 字节，这样至少不会踩到大多数默认类型的红线。如果具体对象确实需要更大对齐，比如 64 字节，必须在分配信息里单独记录。

5.2 生命周期错位：Arena 是悬垂指针温床

Arena 的 reset 操作会瞬间让所有已分配对象变成野指针。凡是分配过但没有及时消费，或者塞进了异步队列的对象，在 reset 后访问就会读到被覆盖的数据。这类 bug 不是必现的，它只在内存被下一次分配覆盖时产生，调试难度极高。

我自己的解法是在 Arena 对象的类说明里用醒目标注“生命周期不得超过 Arena”，同时在 Debug 模式下给每个分配块填充固定的模式字节，reset 时改成 0xDE。这样一旦异步代码访问到已被 reset 的对象，大概率能一眼看出数据被改了。还有一个更彻底的规避办法：异步路径需要长生命周期数据时，在 reset 前显式深拷贝到独立内存。虽然看起来“费了一次分配”，但整体成本依然可控。

5.3 C++ 分配器和容器的状态语义冲突

C++ 标准要求同一类型的分配器互换，也就是说随便两个相同类型的 std::allocator 对象去释放对方分配的内存，程序必须能正常工作。标准库容器的 move、swap 很多操作依赖这个假设。自定义分配器如果内部持有状态（比如指向某个池子），没有正确处理这些场景，容器拷贝或移动时就会出现“一个池子释放另一个池子内存”的严重问题。

实践里最容易踩的是 std::pmr::vector 的 move 操作。pmr 容器 move 后，新容器会继续持有原容器的 memory_resource 指针，这个行为比较直观；真正容易出错的是你自己构造一个临时 memory_resource 传给容器后容器转头又被 move 或者拷贝，资源生命周期很容易失控。我的建议是：池子资源对象的生命周期必须比所有使用它的容器更长，最好统一由某个 Manager 持有，不要裸传指针。

5.4 内存不归还的错觉：RSS 看着涨上去就心慌

固定大小池和线程本地缓存都会为了性能保留大量空闲内存，不会频繁归还给操作系统。这会导致一个问题：程序启动时 RSS 很漂亮，跑一天后 RSS 稳定在一个高位，用 top 看好像内存泄漏了。

这不一定是泄漏，而是分配器“持币待购”。想要区分，可以观察长期稳态：如果 RSS 涨到某个水平后不再持续增长，基本能确认是缓存保留而非泄漏；如果一直线性上涨，那才是真泄漏。当然，如果上层业务对 RSS 峰值有严格限制，分配器应当增加内存回收逻辑，把连续空闲内存池归还给系统，但这会牺牲一部分命中率，需要权衡。

5.5 double free 和多线程释放错位：正确性调试的灾难

自定义分配器通常不做 malloc 那样的双 free 完整检测，因为那个检测本身要付出额外成本。两份“看似独立”的池子如果对象被跨池释放，轻则重写元数据，重则直接破坏链表结构，导致下次分配时崩溃。这类问题最可恶的地方是：崩溃现场和真正的错误点往往隔了十万八千里。

为了缓解，我在开发版本里给每个池子加了 magic number 和 owner_id 校验，释放时检查目标地址属于当前池子再操作。线上版本则直接关闭这段校验代码，不为性能埋单。Debug 和 Release 保持两套行为，是这类底层代码的常见做法。

6. 选型框架：别拿着锤子找钉子

做了这么多测试和踩坑，最重要的收获不是“哪个分配器最快”，而是一套做决定的方法。分配器是底层组件，一旦选错，上层所有代码都会跟着遭殃，所以直接给出几条我自己的判断标准。

6.1 先上 profiler，别靠猜

先跑 perf 或者 heaptrack 这类工具，看清楚分配到底占多少 CPU、每个请求平均分配多少次。如果分配占比在整个 CPU 时间洞里不到 5%，自定义分配器带来的收益就可能被整体复杂度吃光。毕竟它带来的不是新功能，而是提速，幅度不显著等于白做。

分配热点明确后，再看生命周期特征：是批次性分配还是持续交错？对象尺寸是否固定？是单线程还是多线程？这三个问题的答案基本就能锁定选择范围。批次性分配优先考虑 Arena，固定尺寸高频用固定池，多线程尺寸混杂则可能得组合实现线程本地缓存。

6.2 直接从场景映射到分配器

我习惯用一个简单的判断流程：先确认热点；再分析分配序列；然后从“单线程、同构小对象、生命同期短”这种最简单组合开始，能选到满足需求的、实现最简单的方案为止，不贪多、不炫技。

下面是我自己整理的行动参考表：

6.3 落地时的渐进策略

对于现有系统，最忌讳的做法是一口气把所有分配都换成自定义分配器。分配器属于全局基础设施，任何一块不兼容都会引发诡异问题。稳妥策略是先在热路径上用接口隔离，比如把一段高频代码的分配收敛到 pmr memory_resource 上，评估收益后再逐步推广。

我当时在网关里的做法是：热路径上的请求上下文用 Arena，固定大小的连接对象用内存池，其余逻辑保持默认 malloc 不动。线上指标显示 GC/内存无关的吞吐提升了约 28%，P99 从 12ms 降到 8ms 左右。这个收益不是分配本身那几十纳秒带来的，更多是缓存局部性变好和锁竞争消失的复合结果。

6.4 最后一条：不要爱上自己的分配器

有一点我想特别提醒：分配器优化是有边际递减效应的。初版永远是最容易的，收益也最大；后面每加一个 feature，比如跨线程迁移、内存复用、对齐升级，复杂度和风险都会非线性增长。我见过很多团队沉迷于把分配器雕成完美艺术品，最后在正确性问题上耗费了数周时间，实际收益却没怎么增长。

每个分配器都必须有它的退出条件：当需求超出当前实现的适用场景，或者收益已经无法覆盖维护成本时，就该果断承认它已经完成了历史任务，考虑换一种设计，而不是继续打补丁。

如果让我给一个最简单的验收标准，那就是：优化后的单次分配耗时在目标负载下稳定在 50 纳秒以内，P99 对系统延迟毛刺的影响小于 1%。达到这个标准后，请把时间花在别的地方。我自己做完这套对比后，很长一段时间内都没再碰过分配器代码，因为真正的收益已经全部落袋了。