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

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

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

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

　　因为每个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就是底层接口单次分配的内存块，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，分配的时候，会首先从线程运行的core上的ChunkArena分配，如果没有合适的，会从其他Core的ChunkArena里分配，再分配不到，才会从system_allocate，这样做的目的，是减少内存cache量。

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

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

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