调用malloc分配内存大概是微秒级别，高并发低延迟系统的关键路径上，要慎用malloc/new，特别是在线程数量很大的情况下。

给一个测试数据：linux 64位系统，标准库malloc，单线程，gcc开O3优化，分配的size在4M以下随机，平均每次分配大概0.1-3微秒，具体数值跟分配行为有关，跟分配后是否free有关。

多线程下的malloc性能开销，我没有测，应该会比单线程下差很多很多。

微秒级的执行时间是什么概念？一般而言，简单的函数调用，里面做个加减乘除+拷贝几十个字节+逻辑判断，应该是几十个纳秒级别，由此可见，malloc/new调用是比较慢的。

我们来看看doris是怎么做内存管理的，推测这个方案是从某个开源库借鉴（chao）过来的，any way，性能不错，值得研究。

Doris内存管理分三层

系统配置器（system_allocator）

• 封装系统/标准接口，提供allocate/free接口
• allocate(size)根据size调用posix_memalign()或者mmap()
• free()接口调用munmap()或者free()
• 会在分配的时候做内存对齐。

块配置器（chunk_allocator）

• 块（Chunk）：通过system_allocator::allocate接口分配的内存块，包含内存块首地址指针、尺寸、core_id等信息
• 为每个CPU core维护一个chunk_arena
• 每个chunk_arena包含一个chunk_list
• chunk_list为每个size维护一个该size的chunk集合
• 为了减少各种size的数量，只维护固定size的chunk集合，比如8、16、32、64、128、256...，所以如果分配请求的大小是34字节，那么会向上圆整到64
• 块配置器会使用系统配置器分配/回收内存
• 块配置器是单件（唯一实例）

内存池（MemPool）

• 对外提供allocate()、clear()、free_all()等接口
• 维护通过allocate接口分配的ChunkInfo的列表，ChunkInfo在Chunk上增加了一个已分配字节数
• 内存池会通过块分配器分配大块，每次分配的大块的大小会按X2（策略决定）增加，从而确保不会频繁调用块分配器的allocate接口
• 通过内存池的allocate接口分配的内存，不支持单个块free，只支持统一释放：free_all()
• clear()接口支持内存复用

三者之间的关系如下

system_allocator的作用

屏蔽了动态内存管理相关的底层系统调用和标准C/Posix编程接口

• 如果单次申请的chunk size大于某个阈值，那就调用mmap/munmap
• 否则调用posix_memalign
• 上层应用不再直接调用底层API，而是调用system_allocator封装的编程接口：allocate/free

chunk_allocator是怎么工作的？

chunk_allocator是system_allocator的上层，会使用system_allocator的allocate/free接口申请和回收内存块。

chunk_allocator是MemPool的下层，提供allocate和free接口供MemPool使用。

chunk_allocator主要是减少了多线程竞争，chunk_allocator维护core_num个ChunkArena对象，该对象内维护一个chunk_list，为size=2^n的每个块维护一个free list，内存申请的时候，会对请求的size向上圆整。

因为每个core都有一个ChunkArena对象，所以上层应用代码申请内存的时候，先获取代码正在哪个核上执行，从而找到对应的ChunkArena对象，再通过size找到对应的free列表，再从该free list上摘除一个块。

多个逻辑线程依然可能调度到同一个核上执行，虽然多个线程不会在一个核上同时执行申请动态内存，但多个线程在一个核上交错执行（申请内存）的情况，依然会引发对free list的数据竞争（虽然这种情况出现的概率很小），这时候只需要用test_and_swap原子操作不停尝试就行了，如果尝试一定次数还不成功，则执行线程主动yield，让出CPU，从而让另一个在该核上执行内存分配的线程有机会继续执行，进而修改atomic_flag，然后之前yield CPU的线程被重新调度执行。

TAS（test and swap）是很快的，且冲突概率变得非常小（因为每个核都有一个atomic_flag，不会所有线程竞争一个锁），这样的免锁设计，让分配内存变得很高效。

chunk_allocator也做了一层cache，通过chunk_allocator::free释放的内存块，并不一定会真正调用底层的free，只在预留size超过限额的情况下，才会调用system_allocator的free()，这样进一步减少了对系统底层动态内存管理相关API的调用。

chunk_allocator是单件，唯一实例。

MemPool设计

咱们进一部分分析MemPool的设计，先给一张MemPool的图：

MemPool设计

MemPool的作用

内存池在system_allocator/chunk_allocator/MemPool的层次结构中，位于顶层，它依赖于下层chunk_allocator，间接依赖system_allocator，下层的类不反向依赖于MemPool。

先说Chunk和ChunkInfo。

Chunk就是底层接口单次分配的内存块，Chunk持有内存块首地址data，内存块大小size，以及分配的时候执行线程在哪个core上执行。

ChunkInfo包含Chunk，同时多了一个int allocated_size，这是因为，为了减少对
system_allocator::allocate()的调用次数，所以单次分配的chunk会比较大，几K，几十K，甚至XX M（兆），这个大的size记录在chunk->size上。但是，上层应用一次分配的内存可能比较小，几十字节之类，所以，该chunk还有多少字节可用（已经使用了多少字节），需要有一个记录，这就是allocated_size，相当于一个游标，每次从该chunk分配x字节，那就把allocated_size这个游标往增长的方向移动x字节（实际上会考虑到对齐）。

所以，对
system_allocator::allocate()的调用，相当于批发进货。对MemPool::allocate()的调用，相当于零售。效果上，就是减少了底层API的调用频率，减少了多线程竞争。

MemPool持有一个next_chunk_size，它表示下次调用ChunkAllocator分配接口allocator的时候，需要分配多大，它被初始化为4K，下次分配的时候，会增加到8K，当然如果下次申请的size大于8K，则会取max。

next_chunk_size会一直增加，直到触达最大配置值，这样的设计，目的还是为了减少底层分配次数。

每次ChunkAllocator::allocate()都会返回一个Chunk，进而包装为ChunkInfo，被MemPool管理起来，所以MemPool会有多个ChunkInfo，用chunk_index标识chunk。

MemPool记录一个current_chunk_idx，这个idx记录了上次成功分配的ChunkInfo，下次分配的时候，先从current_chunk_idx指向的chunkInfo里尝试分配，如果该ChunkInfo的剩余内存空间不够，则会查找其他ChunkInfo，直到找到能满足分配请求的ChunkInfo，如果现有的所有ChunkInfo都不满足，那就走ChunkAllocator的allocate，并把新申请的Chunk，放入ChunkInfo list。

MemPool不支持单次分配的内存free，但是支持free_all，这会free该MemPool的所有Chunk。

MemPool::Clear()接口不会真正free Chunk，而是会重置allocated_size，复用原内存chunk。

一个细节，关于ChunkAllocator，分配的时候，会首先从线程运行的core上的ChunkArena分配，如果没有合适的，会从其他Core的ChunkArena里分配，再分配不到，才会从system_allocate，这样做的目的，是减少内存cache量。

我们做内存池有几个目标

1. 吞吐，吞吐越大越好，能满足各种不同size，各种内存分配场景的大吞吐最好。
2. 提高存储空间利用率，千方百计减少碎片（内碎片+外碎片，不懂请补课）。
3. 为了提高速度，我们经常要做cache，但是cache多了，会造成宝贵的内存资源的浪费，所以，需要balance。
4. 最后，非常重要的一点，提高cache利用率。

大家可以结合以上几点，慢慢体会该内存池的方式，是如何做到的。

很多人会质疑内存池的必要性，我只能说，如果线程很多，并发很大，时延要求也高，那可能真的需要加这么一层，不信你可以去测试一下。

不过，所有的方案都有缺点都有优点，都需要通用性，专用性，性能，效率，内存利用率等各个方面做出权衡，要结合业务，结合上层代码来定制。

Nginx，clickhouse的内存管理方案也不错，读者有兴趣可以去找来看看。