内存分配器擂台：jemalloc vs tcmalloc vs mimalloc vs glibc

打开任何一篇分配器对比文章，你会看到 micro-benchmark：malloc/free 100 万次，记录耗时。jemalloc 3.2 ns，tcmalloc 2.8 ns，mimalloc 2.5 ns，glibc 4.1 ns。

然后呢？你选了最快的那个，部署到生产环境，跑了三天，RSS 涨到了物理内存的 80%。OOM killer 来了。你切回 glibc，问题消失了。

分配器的性能不是 malloc/free 的速度。是长时间运行后的碎片率、多线程竞争下的尾延迟、以及大小类切换时的内存利用效率。

一、四个分配器的设计差异

先把架构搞清楚，然后才能理解性能数据。

glibc (ptmalloc2)

Linux 默认分配器。Arena-based 设计。

• 每个线程绑定一个 arena（最多 8 × CPU 核数 个 arena）
• 小对象（<512B）用 fastbins + smallbins，LIFO 链表
• 大对象（>128KB）直接 mmap
• 碎片来源：bins 之间的间隙 + arena 之间的不均匀

glibc 的 fastbin 在高并发下有一个反直觉的行为：它用的是单链表 + mutex，不是无锁。在高并发 malloc/free 时，arena lock 竞争是主要瓶颈。

jemalloc

FreeBSD 默认分配器，Facebook 用了十几年。

• Thread cache + arena + extent 三层架构
• 小对象按 size class 分桶（8B, 16B, 32B, 48B, …），每个桶预分配 slab
• 碎片控制：定期做 dirty page purge，把不用的页面还给 OS
• 优势：碎片率控制最好，长时间运行 RSS 最稳定

tcmalloc (Google)

Google 全家桶用的分配器。

• Per-thread cache + central free list + page heap 三层
• Transfer batch：线程 cache 用光时，从 central list 批量拿一批（减少锁竞争）
• 优势：多线程小对象分配速度最快
• 弱点：碎片控制不如 jemalloc，大对象分配较慢

mimalloc (Microsoft Research)

最年轻的选手，2019 年发布。

• Per-thread heap，每个 heap 由固定大小的 page 组成
• Free list sharding：把 free list 分散到每个 page 里，减少 cache miss
• 延迟释放：其他线程释放的块先放进 local free list，稍后再合并
• 优势：micro-benchmark 最快，cache 友好度最高

二、Micro-benchmark：参考但不要信

标准测试：单线程和多线程下 malloc/free 混合操作。对象大小分布：70% <256B, 20% 256B-4KB, 10% >4KB。

单线程

mimalloc 在单线程下最快。原因是 free list 在同一个 page 里，cache locality 极好。

16 线程

glibc 在多线程下被吊打。arena lock 的竞争太重了。其余三个都有 per-thread cache，差距在 20% 以内。

但这些数字在真实应用中几乎没有参考价值。因为真实应用的 malloc/free 模式和 micro-benchmark 完全不同：对象生命周期不均匀、分配和释放不在同一个线程、内存使用量有波峰波谷。

三、碎片率：24 小时实测

测试方法：把四个分配器分别嵌入同一个 HTTP 服务器（基于 libevent 的 JSON API 服务），用模拟流量跑 24 小时。

流量特征： - 请求体 200B-10KB（JSON 解析 + 序列化，大量小对象） - 每个请求分配 15-30 个对象，生命周期从 100us 到 5s 不等 - 稳态 QPS: 20,000 - 每 2 小时有一次流量高峰（QPS 翻倍，持续 10 分钟）

jemalloc 在长时间运行后碎片率最低。 24 小时后 RSS 只有 95 MB，而 glibc 涨到了 210 MB。差 2.2 倍。

原因： 1. jemalloc 的 dirty page purge 机制定期把不用的页面通过 madvise(MADV_DONTNEED) 还给 OS 2. jemalloc 的 size class 更细粒度（比 glibc 多 50% 的 size class），内部碎片更小 3. glibc 的 arena 之间内存不共享，一个 arena 的空闲内存不能被另一个 arena 使用

tcmalloc 碎片率高的原因：per-thread cache 的 transfer batch 机制会预取一批对象，但如果线程的分配模式变化了（比如请求类型变了），预取的对象就浪费了。Google 内部已经意识到这个问题，新版 tcmalloc 加了更积极的回收策略。

流量高峰后的恢复

关键指标：流量高峰（QPS 翻倍 10 分钟）结束后，RSS 能不能降回去？

glibc 几乎不回收。这是 Linux 运维常见的困惑：“为什么我的进程 RSS 只涨不降？”——因为 glibc 的 ptmalloc 不积极做 madvise。内存 free 了但没还给 OS，留在 arena 里等下次分配。

如果你的应用有明显的波峰波谷，jemalloc 的碎片回收能力值三倍内存。

四、尾延迟：分配器也会卡你

分配器不只影响内存占用。在错误的时机，一次 malloc 可能耗时几十微秒。

测量方法：在 HTTP 请求路径上记录每次 malloc 的耗时，统计分位数。

glibc 的 P99.99 比其他三个高一个数量级。原因：arena lock 竞争。当多个线程同时需要从同一个 arena 分配，其中一个拿到锁，其他全部等待。38 微秒的 malloc 对于 P99.9 延迟要求在 1ms 以内的服务来说，是不可接受的。

tcmalloc 的 P99.99 也不低（8.2 us）。原因是 central free list 的锁——per-thread cache 用光后需要从 central list 批量取，这一步有锁。

mimalloc 和 jemalloc 在尾延迟上表现最好。mimalloc 的 free list sharding 设计使得几乎所有分配都能在 page-local free list 里完成，不需要任何锁。

五、选型建议

怎么切换：

# 编译时链接
gcc -o myapp myapp.c -ljemalloc

# 运行时注入 (不需要重编译)
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.2 ./myapp

# Rust 项目
# Cargo.toml: [dependencies] tikv-jemallocator = "0.5"

不要看完这篇文章就换分配器。先在你的应用上跑 24 小时对比测试。分配器的表现高度依赖你的 malloc/free 模式——上面的数据是这个特定 HTTP 服务器的，你的应用可能完全不同。

延伸阅读：

• SQLite 是怎么做到”十亿行每秒”的 – SQLite 用自己的 page allocator 避免 malloc 碎片
• Go 调度器深度拆解 – Go 的内存分配器 (mcache/mcentral/mheap) 借鉴了 tcmalloc 的设计

参考资料：

1. Evans, J. (2006). A Scalable Concurrent malloc(3) Implementation for FreeBSD. – jemalloc 的原始论文
2. tcmalloc 设计文档 – Google 官方
3. Leijen, D. et al. (2019). Mimalloc: Free List Sharding in Action. Microsoft Research.
4. glibc malloc internals – ptmalloc2 的实现细节