简要分析 Jemalloc 与常见内存分配器

Question

工作中造了个的虐心小轮子–内存分配器，本来是想直接移植 Jemalloc，但综合业务场景还真不太合适。主要原因是我们的 API server 的 client 上限是已知的，而且活跃的 client 长期维持在一个稳定的数量，api 的 key 和 value 都小于 4k。总的来说，server 的内存需求是上限是固定，且主要是小内存分配。我们更希望做一个能预先分配好上限内存，超过上限时能向系统申请，长期闲置时能回收到系统。

当然稍微修改下 Jemalloc 也能满足这些需求，但 Jemalloc 对大内存的管理和 Tcache 机制比较复杂，作者为了足够的高效用了各种 trick 的宏定义和数据结构。总的来说，我们的需求比较简单，引入复杂机制的代码后期定位问题的时候需要完整的理解 Jemalloc，加大了工程维护的时间成本。

因此，我们决定借鉴 Jemalloc 的核心思想针对业务做个可预分配的，可自定义的，支持多规模小 size 的内存分配器。结果也是很乐观的，在模拟正常业务的场景下对比了我们的实现和 Jemalloc、TCmalloc、glibc 的性能，提升了 3-4 倍时间效率（没有开启基于 thread local 实现的线程无锁内存分配机制）。这已经满足了基本需求，对于 IO 来说内存分配的时间损失还是太小了。

Jemalloc 很优秀维护快 10 年，作者尝试能想到的想不到的优化，各版本数据结构改动变化挺大的。以下算是浅显的对比各开源组件的 slab 实现和 Jemalloc 的异同，主要是对 malloc() 和 free() 的内在探究。有时间再总结下我们的 slab 实现，有很多地方和 Jemalloc 还是不同的。主要的我们的场景足够简单，不需要做成通用的模块。也希望能听到不同的声音，激励提高。