内存池这个东西我在项目里手写过好几次每次写完都觉得“这不就是个链表吗”但每次深入调优的时候又总能被各种边界问题打脸。网上讲内存池原理的文章很多真正能落地、能处理多线程、能做内存对齐、能排查线上崩溃的实操内容反而少。这篇文章我就用一次完整的自定义实现经历把从设计、编码、测试到踩坑的全过程拆开讲清楚。如果你在写网络服务、游戏服务器、高频交易引擎或者任何对分配延迟敏感的模块又或者你只是好奇 malloc 背后到底在忙什么这篇文章都值得看完。我会给出完整的 C 实现代码也会解释每个设计决策背后的原因——包括那些我最初写错、后来才想明白的细节。1. 内容整体设计与思路拆解1.1 为什么系统自带的 malloc/free 不够用先搞清楚一个问题我们到底在优化什么。malloc 和 free 是 C/C 程序员最熟悉的两个函数但它们实际上是通用内存分配器要同时满足不同大小、不同线程、不同生命周期对象的分配需求。这意味着它内部要维护复杂的空闲块管理结构还要处理线程间的锁竞争。你每次调用 malloc它可能要走一遍“找到合适空闲块 - 拆分 - 更新元数据”的流程分配出的内存块头部还要附加一些簿记信息。我过去在压测环境里用 perf 看过一个网络网关程序的运行情况当时发现malloc和free占用的 CPU 竟然接近 12%。这个数字在业务繁忙时还会继续上涨因为多线程同时分配内存时分配器内部的锁竞争会加剧线程越多等待越明显。而在高频交易场景里分配延迟的抖动比平均延迟更致命——一次 gc 或一次锁等待造成的几百微秒毛刺足够让整个交易策略偏离预期。内存池的自定义实现本质上就是针对这种问题做“手术式优化”。核心思路只有一句话既然通用分配器要照顾所有场景那我们就针对自己的特定场景预先分配好一大块内存自己维护分配和回收的规则把分配路径上的开销降到最低。1.2 内存池有哪些常见形态怎么选型很多人一上来就写“一个类里面一个链表”但实际项目中内存池的形态千差万别。我按自己的实践把内存池分成这么几类定长内存池所有块大小一致比如 64 字节、128 字节。适合对象类型固定的场景比如每连接一个 Buffer每请求一个 Context。实现最简单分配和释放都是 O(1)这是大部分入门者首选。变长内存池块大小不固定需要引入空闲块按大小分级管理通常用 slab 或 buddy system 思路。逻辑复杂很多适合自研内存分配器的进阶场景。环形内存池Ring Buffer / Arena只推进不回收通过“水位”或“游标”管理内存适合帧同步、一次性任务等对象的生命周期很短且批量释放的场景。这个在后面我会给出实现思路。线程局部内存池ThreadLocal Cache每个线程持有自己的池子申请内存时优先从本地产出减少锁竞争不够再向全局池索要。这是现代高性能内存分配器如 tcmalloc、jemalloc的经典设计。需要先说清楚内存池不是银弹。如果你的业务对象生命周期长短差异巨大、大小变化剧烈那用内存池反而会浪费大量内存。我在项目组里定的选型原则很简单——只有当你反复测量确认分配器确实是瓶颈且对象有清晰的复用特征时才值得引入内存池。这个判断帮我避免了好几次过度设计。1.3 我的设计目标与硬性指标这次自定义实现我给定了四个硬指标全部来自工程落地时的客观需求第一单线程分配释放路径必须是 O(1)不能因为内存池的出现引入额外的遍历或查找。第二多线程环境下不能有全局锁作为唯一瓶颈。至少要做到“多数情况下无锁分配”只在扩容等极少数路径上碰锁。第三内存对齐必须可控常见的对象要求 8 字节或 16 字节对齐分配器必须保证任意返回的指针都满足对齐要求。第四所有分配出来的内存都要能统计比如池内总块数、空闲块数、最高水位、溢出次数这些指标线上排障时非常有用。另外我决定把它做成一个“定长 线程局部 全局兜底”的混合结构既能满足单线程场景的高速分配又能应对多线程并发不至于在测试阶段就崩掉。下面先从最核心的数据结构讲起。2. 核心细节解析与实操要点2.1 空闲链表的关键不用额外存储只做指针复用定长内存池最巧妙的地方在于它不需要为“空闲块列表”单独分配任何额外内存。因为我们管理的就是空闲内存块这些内存块本身就可以用来存指针。每个空闲块的前 8 个字节会被 reinterpret_cast 成一个指向下一个空闲块的指针。也就是说池子的 freeList 头指针指向第一块空闲内存那块内存的前 8 个字节又存着第二块空闲内存的地址依次串成一个单链表。分配时从头弹出一块同时更新头指针释放时把内存块头 8 个字节指向前一个头再更新头指针。这个设计让内存池空闲块的管理开销为零不额外占用一字节。我第一次看这个实现时觉得它就是“白嫖”理解以后才发现这其实是所有高性能分配器的通用招数。要注意的坑是如果你要把内存池泛化成支持模板对象分配出去的块有被写入数据的时候千万不能把“块的前 8 个字节”想成永远可用的头部空间。一旦对象构造写入这块内存空闲链表指针就被覆盖了所以释放回池子时一定要把内存块视作“原始未构造内存”重新用它存 next 指针是没有问题的因为对象已经被析构了。2.2 内存对齐与最小块大小内存对齐这个事如果你只是自己玩可以不管。一旦放到生产环境比如传给网络协议栈、SIMD 指令集或者某些严格要求 16 字节对齐的第三方库不对齐的指针会直接导致性能下降甚至崩溃。我实现内存池时块大小计算公式是size_t alignSize std::max(sizeof(void*), (size_t)8); while (blockSize % alignSize ! 0) blockSize;这里8是一个保守的默认对齐值覆盖了 64 位系统上大多数内建类型和指针。如果业务明确要求 16 字节或 32 字节对齐把这个值替换一下就行。另外最小块大小要至少能存下一个指针否则空闲链表没法串所以取sizeof(void*)兜底。默认对齐为 8 字节的情况下如果你申请 24 字节的块实际会分配 24 字节因为 24 是 8 的倍数但如果你申请 20 字节实际会分配 24 字节。这种舍入会带来一次性的“对齐浪费”但换来的是任意返回指针都对齐值得。2.3 性能背后的 Cache 友好性很多人写内存池只盯着“少调用 malloc”但实际上内存池还有一个隐藏优势内存局部性更好。不断 malloc 出来的对象散落在堆的各个角落遍历时 CPU 缓存行命中率很低。而内存池预先分配一整块内存再从这个连续区间切块大量对象会集中在连续的几页内存里遍历链表或批量访问对象时缓存命中率明显更高。我在一个事件管理模块里用内存池替换普通 new 之后除了分配耗时下降整个事件遍历的耗时也降了原因就是对象们在内存里排列得更紧凑。不过要泼一盆冷水这个优势只在“对象位于同一块池子”时成立。如果池子太大或切块后对象生命周期差距极大分配出去的内存可能散布在池子的各个角落反而会让缓存局部性变差。实际项目里要根据对象数量估算池子的初始大小尽量保持中短期复用周期。2.4 线程安全设计全局锁、分区池、ThreadLocal多线程使用同一内存池时freeList 的操作存在数据竞争。最简单的方案是给分配和释放各加一把互斥锁这个方案能保证正确性但性能会退回到“所有线程串行分配”的老路。我的方案是加一个线程本地的小型缓存池。每个线程第一次向全局池索要内存时一次性领取一批比如 64 个块放进线程自己的空闲链表。此后这个线程的分配和释放都只操作本地链表完全无锁。只有当本地链表空了才回到全局池再领一批只有当本地回收的块超过某个阈值才把一部分还给全局池。这个套路跟 tcmalloc 的 thread cache 思路一致只是实现更轻量。代码部分我会给出完整实现这里先记住一个重点ThreadLocal 池的块放回全局时必须把“块地址”本身作为归还单位而不能把整个线程池的 chunk 交给全局否则后续分配可能造成跨线程的悬垂指针。3. 实操过程与核心环节实现3.1 定长内存池的基础版本单线程安全先上一个干净的基础版本它实现一个定长块内存池支持任意字节对齐单线程下无锁多线程下靠外部加锁。这个版本用来理解内存池核心机制最合适。// FixedMemoryPool.h #pragma once #include cstddef #include cstdint #include vector #include cassert class FixedMemoryPool { public: FixedMemoryPool(size_t blockSize, size_t initBlockCount 64) : blockSize_(normalize(blockSize)) { expand(initBlockCount); } ~FixedMemoryPool() { for (auto* chunk : chunks_) { ::operator delete(chunk); } } void* allocate() { if (freeList_ nullptr) { expand(blockCountPerChunk_ 1); } void* ptr freeList_; freeList_ *reinterpret_castvoid**(freeList_); allocatedCount_; return ptr; } void deallocate(void* ptr) { if (ptr nullptr) return; *reinterpret_castvoid**(ptr) freeList_; freeList_ ptr; --allocatedCount_; } size_t blockSize() const { return blockSize_; } size_t allocatedCount() const { return allocatedCount_; } size_t freeCount() const { return freeCount_; } private: size_t normalize(size_t size) { const size_t align sizeof(void*) 8 ? sizeof(void*) : 8; size_t aligned (size align - 1) / align * align; return aligned sizeof(void*) ? sizeof(void*) : aligned; } void expand(size_t blockCount) { size_t bytes blockCount * blockSize_; void* chunk ::operator new(bytes); chunks_.push_back(static_castchar*(chunk)); char* p static_castchar*(chunk); for (size_t i 0; i blockCount; i) { void** slot reinterpret_castvoid**(p); *slot freeList_; freeList_ slot; p blockSize_; } freeCount_ blockCount; } size_t blockSize_; void* freeList_ nullptr; std::vectorchar* chunks_; size_t allocatedCount_ 0; size_t freeCount_ 0; size_t blockCountPerChunk_ 64; };这个版本的逻辑很直白。allocate()如果 freeList_ 为空就扩容否则从链表头弹出一块deallocate()把内存块头 8 字节指向当前链表头然后自身成为新头部。这么做的好处是分配和释放都不需要扫链表也不需要在内存块头部放任何持久化的管理字段。注意扩容策略的细节初始创建时我给了 64 块之后每次扩容块数量翻倍。这个“倍增”策略并不是拍脑袋它让扩容次数保持对数级别——初始 64、128、256、512…… 连续分配 100 万块时扩容只发生十几次相比每次只扩固定数量又避免了大块连续分配的内存浪费。3.2 把 freeList 换成无锁结构支持多线程基础版本在多线程下共享同一个 freeList_ 是不安全的所以我把它升级为带线程缓存的版本。核心思路每个线程持有一个局部空闲链表分配时优先从局部拿局部空了再去全局领一批。class ThreadCacheMemoryPool { public: ThreadCacheMemoryPool(size_t blockSize, size_t batchSize 64) : pool_(blockSize, batchSize), batchSize_(batchSize) {} void* allocate() { auto cache getTlsCache(); if (cache.localFreeList nullptr) { refill(cache); } void* ptr cache.localFreeList; cache.localFreeList *reinterpret_castvoid**(cache.localFreeList); cache.localAllocated; return ptr; } void deallocate(void* ptr) { auto cache getTlsCache(); *reinterpret_castvoid**(ptr) cache.localFreeList; cache.localFreeList ptr; cache.localFreed; if (cache.localFreed batchSize_ * 2) { releaseToGlobal(cache); } } private: struct TLS { void* localFreeList nullptr; size_t localAllocated 0; size_t localFreed 0; size_t localBatch 0; }; TLS getTlsCache() { static thread_local TLS tls; return tls; } void refill(TLS cache) { size_t got 0; { std::lock_guardstd::mutex lock(globalMutex_); for (size_t i 0; i batchSize_; i) { void* ptr pool_.allocate(); *reinterpret_castvoid**(ptr) cache.localFreeList; cache.localFreeList ptr; got; } } cache.localBatch got; } void releaseToGlobal(TLS cache) { std::lock_guardstd::mutex lock(globalMutex_); while (cache.localFreeList ! nullptr) { void* next *reinterpret_castvoid**(cache.localFreeList); pool_.deallocate(cache.localFreeList); cache.localFreeList next; --cache.localFreed; } cache.localFreed 0; cache.localFreeList nullptr; } FixedMemoryPool pool_; size_t batchSize_; std::mutex globalMutex_; };细节上refill 是一次性向全局池要 64 块然后倒序挂到线程本地链表上保证分配出来的顺序是原顺序。releaseToGlobal 则是等线程本地回收超过一定量之后把整批返还给全局池避免每个线程都把小块留在自己手里导致全局池大量空洞。这里要特别提醒ThreadLocal 缓存池的正确性取决于一个隐含前提——归还到池里的块不会再被原来的线程持有。也就是说一个块的物理地址在“线程 A 释放 - 线程 B 分配”之间必须经过全局池的中转。上面代码里releaseToGlobal把本地块全部交回全局池之后其他线程才能拿到这个过程是安全的。如果你在 release 前就把块还给另一个线程内存竞争就会非常隐蔽。3.3 环形内存池Ring / Arena实现思路环形内存池在帧同步、事件流处理里非常实用。它的特点是不单独管理空闲块而是维护一个大的环形缓冲区只用一个写游标不断前进分配就是移动游标释放是整体复位。它其实不是传统意义上的“池”更像一种一次性内存竞技场。我实现时借鉴的是 LMAX Disruptor 里的环形缓存思路class RingMemoryPool { public: RingMemoryPool(size_t capacityBytes) : capacity_(capacityBytes) { buffer_ static_castchar*(::operator new(capacity_)); writePos_ 0; } ~RingMemoryPool() { ::operator delete(buffer_); } void* allocate(size_t size) { size_t aligned (size alignof(std::max_align_t) - 1) ~(alignof(std::max_align_t) - 1); size_t start writePos_.load(std::memory_order_relaxed); size_t end start aligned; if (end capacity_) { end aligned; // 从头绕回 } writePos_.store(end, std::memory_order_relaxed); return buffer_ start; } void reset() { writePos_.store(0, std::memory_order_relaxed); } private: size_t capacity_; char* buffer_; std::atomicsize_t writePos_; };这个版本适合单生产者或者用原子操作放行多生产者但它不能单独释放某个块只能整体 reset。所以用它的场景必须是“一批对象建立、统一销毁”比如一次网络请求处理中的所有临时对象、一帧画面更新时的临时数据。如果中间有个别对象活得特别久环形内存池就会泄漏整块内存直到 reset 才会释放这一点在项目使用前必须想清楚。我在一个嵌入式相机的帧处理管线里用过这种环形池。当时每帧需要创建数十个临时坐标点结构体大部分存活时间不超过一帧。用环形池以后分配成本变成一次原子加法帧处理速率提升了约 18%。但后来发现某个宽动态算法会保存其中几个点供下一帧使用直接导致数据被后续分配覆盖排查了一个下午才定位到问题——所以环形池的“统一生命周期”约束一定要写在接口文档里甚至可以在调试模式下加一层校验宏来检查是否存在跨重置周期的引用。3.4 无锁内存池的进阶方向如果你真的想在多线程下完全无锁还有一种常见的做法是给每个线程分配独立的连续内存区间线程之间不存在竞争。最直接的实现是线程 ID 或 ThreadLocal 直接索引到内存池数组里的一个实例class PartitionedMemoryPool { public: void* allocate() { auto pool getLocalPool(); return pool.allocate(); } void deallocate(void* ptr) { // 需要想办法知道 ptr 属于哪个子池 auto pool getLocalPool(); pool.deallocate(ptr); } private: FixedMemoryPool getLocalPool() { static thread_local FixedMemoryPool local( 64, 1024); return local; } };这里的麻烦在于 deallocate 时如果 ptr 是另一个线程分配的你没法立即确定该把它还给哪个子池。一种策略是把子池的指针记录在块的前 8 字节里不过这会污染对象数据只在不使用前 8 字节的对象上可行更通用的是在块头额外加一个池 ID 字段。后者会增加内存占用但能保证释放路径也能无锁。我实际生产环境见过一种不用块头 ID 的无锁思路直接给入参按地址哈希分流。比如内存池有 64 个子池根据poolIndex (ptr 12) % 64来计算它属于哪个子池。因为 64 是 2 的幂这实际上取的是地址的中间几位。这个方案依赖地址布局的均匀性如果某个子池扩容产生的新 chunk 地址落在同一个低位索引区间就会分布不均匀需要为每个子池的 chunk 采样校准。这种偏工程向的骚操作我自己只在 OS 级别的内存分配器里看过业务代码里很少需要。3.5 测试与基准验证代码写完之后测试是绕不开的。我推荐组合使用三种测试手段第一是单元测试。写 10 万个随机分配和释放操作每隔一段时间检查一遍池的 allocatedCount 和 freeCount 是否平衡再模拟释放 nullptr、重复释放、错误的地址释放等异常路径确保池在这些错误下行为可预测直接 assert而不是崩溃。第二是内存错误检测工具。用 AddressSanitizer 编译运行测试程序它能在分配释放的瞬间捕获越界读和 use-after-free。我自己写内存池时最依赖的就是 ASan它在开发期几乎能抓出 90% 的内存隐患。第三是性能基准。我写一个 benchmark对比“直接 new/delete”和“内存池分配”在连续分配 100 万次对象时的耗时。我的测试环境是 8 核机器、64 字节定长块结果大致如下表场景每次分配平均耗时波动幅度malloc / free约 120 ns波动较大偶尔出现微秒级尖峰单线程内存池约 25 ns稳定无尖峰多线程加缓存版本约 30 ns每线程稳定无全局锁竞争这个结果并不意外内存池的内存块已经在池里串好了分配就是改一个指针而 malloc 至少要查空闲链表、做切分、更新元数据。不过要提醒一句如果你的机器内存分配器本身已经做了很好的线程缓存优化现代 Linux 下的 glibc 或 jemalloc单线程差距可能缩小到几十纳秒以内。内存池是否值得引入得拿你的真实负载和真实环境跑完再下结论别只看别人写的 benchmark。4. 常见问题与排查技巧实录4.1 内存越界为什么在内存池里这么难以定位普通 malloc 分配的内存在越界访问时可能会出现段错误但内存池的块一个挨着一个越界很可能只是悄悄覆盖了相邻块的数据程序表面上云淡风轻直到某个看起来毫无关系的逻辑突然取出脏数据。我遇到过最典型的一次一个 128 字节的对象实际写了 144 字节越界部分刚好覆盖了相邻池块的前 8 字节空闲链表的 next 指针。结果下一次分配时freeList_ 被指向了一个非法地址程序在分配阶段才崩溃而根因其实在几百行之外的 memcpy。这种间接崩溃最可怕因为 crash 的栈和真正的错误毫无关系。排查经验分几步首先在写完内存池后用 ASan 编译一遍基准测试让越界在第一次发生时就被抓出来其次在池的每个块末尾加一个“哨兵”区域比如 8 字节固定魔数分配后和释放前各检查一次魔数是否被改再不行就在 test 环境里打开池的分配日志记录每一次分配的调用栈崩溃后用日志还原最近几次分配和释放的现场。日志开关会让性能下降一截只能测试用不能常开。4.2 对齐不对齐的性能差距有些人觉得“反正 CPU 也能处理不对齐访问”这句话在 x86 上部分成立但在 ARM 上就是噩梦。我在 ARM 嵌入式环境里测过不对齐的 int64 访问会导致总线错误即使不崩溃也需要额外的 load/store 周期性能损失可能达到 2 到 4 倍。所以内存池的 normalize 函数里我特意把对齐值从sizeof(void*)改成至少 8 字节并且在分配函数里做了保守的舍入。如果你的数据里有 SIMD 类型比如float4那就需要额外提供setAlignment(16)之类的接口。不要图省事直接把所有块都对齐到 64 字节那是为 cache line 优化的激进做法内存浪费率会直线上升。4.3 多线程场景下性能不升反降的原因用上加锁版本后我遇到过一个问题8 线程并发分配内存池的吞吐甚至比 malloc 还低。无他全局锁把分配完全串行化了所有线程都在抢同一把锁。排查手段是在调用分配函数的外层加性能计数器统计每个线程实际在锁上等待的时间。等锁时间占分配总耗时的比例超过 30%就说明锁竞争已经严重到必须换方案。这时候我的选择不是继续优化锁而是改成上文说的 ThreadLocal 缓存版本——把“锁等待”直接从高频路径上移除只在批量 refill 和归还时才碰锁。如果你不想过度设计可以先试试 C17 的std::mutex换成std::shared_mutex做读写锁但这通常只是杯水车薪。分配和释放本质上都是写操作读锁帮不上忙。4.4 内存碎片与池扩缩容策略还有一个经常被忽略的问题内存池扩容后不会自动缩容。如果某次流量峰值导致池子扩到了 10 万块之后流量回落到 1 万块那 9 万块就会一直占着内存不归还操作系统。我一般留一个手动整理的接口允许业务在低峰期调用compact()把所有空闲 chunk 释放掉。实现方式是遍历 chunks_ 列表记录每个 chunk 里有多少空闲块如果当前 chunk 的空闲比例达到 90% 以上就把这个 chunk 整体归还给系统并从池的 chunk 列表中移除。这个机制能有效防止内存池变成内存黑洞。另外一个细节池的初始化块数量最好根据业务对象的峰值并发量来估算。如果你知道系统同时最多存在 2 万个连接对象池初始就开 2 万个块避免运行时频繁扩容。扩容本身要分配一整块大内存虽然不频繁但一旦发生延迟毛刺是躲不开的。4.5 常见问题速查表我把日常使用中遇到的高频问题整理成了一个表格方便大家按图索骥现象可能原因排查方向分配时崩溃freeList_ 指向非法地址池块越界覆盖了 next 指针用哨兵魔数检查越界开 ASan 编译释放时崩溃ptr 不是本池的块可能来自 malloc 或另一个池打印池地址范围检查分配来源内存占用只增不减池扩容后没有缩容机制添加空闲 chunk 整理接口多线程性能低于 malloc全局锁竞争激烈改用 ThreadLocal 缓存减少锁路径分配出的内存不对齐normalize 函数没有处理对齐检查块大小舍入逻辑环形池数据被覆盖某对象生命周期跨多个重置周期统一生命周期或换用其他池4.6 有没有必要加 header 元数据我见过有些内存池实现会在每个块的头部加一个 Header 结构存块大小、魔数、池 ID 等元数据。这种做法会让内存池实现变简单比如 deallocate 时能通过 header 判断归属但是会付出两个代价一是每块内存要多出 8 到 16 字节的头部开销对于小对象这是不可接受的膨胀二是分配出的指针不再对齐到块的起始地址增加了对齐处理的复杂度。我自己的偏好是定长池不加 header因为块信息本身可以从池对象推导出来只有变长池或跨线程归还频繁的场景才考虑加 header。加 header 的位置也有讲究最好把 header 放在块内而不是块前这样分配出的指针天然对齐。块内 header 的意思是块的可写区域从 offset0 开始就是 header对象数据从 header 之后开始这样对齐依然可控而且 header 不会破坏块的连续性。5. 一些能提升工程体验的小细节最后分享几个我自己觉得很好用、但很多资料不会教的小细节。第一个是给分配函数加调试参数。比如allocate(const char* file, int line)在 Debug 构建下记录分配来源是哪个文件哪一行Release 构建下直接把参数忽略掉。我自己在排查一个 “一个块被释放了两次” 的问题时这个信息帮助极大——我一眼就看到某段代码在异常分支里重复释放了同一个对象。第二个是为内存池实现一个collectStatistics()方法返回当前池里的总块数、空闲块数、最高水位、扩容次数、归还次数。线上服务每隔几秒打印一次通过监控系统能看到池子是否有不健康的增长趋势。这一段在排障值日时比任何工具都好用。第三个是借助 C 的 placement new 和显式析构调用把对象生命周期跟内存生命周期解耦。内存池只负责“内存的分配和释放”对象构造和析构交给调用方// 分配对象 void* mem pool.allocate(); auto* obj new (mem) MyObject(args); // 使用 obj-doSomething(); // 析构 归还 obj-~MyObject(); pool.deallocate(mem);这里要强调一点忘记调用析构函数会带来隐蔽的资源泄漏比如对象内部持有文件句柄或堆内存所以更稳的做法是写一个 RAII 包装类在析构函数里统一执行析构和归还避免裸指针满天飞。6. 写在最后内存池的自定义实现难点从来不是“把块串起来”这个核心思路而是你在真实环境里遇到的那些边界条件——内存越界、对齐、锁竞争、生命周期、缩容策略。写一次内存池相当于把操作系统的内存管理思路亲手实践了一遍对 malloc 背后发生的事情会有完全不一样的理解。我个人的体会是这种底层组件最好不要直接照抄别人的成品代码而是先理解设计取舍再结合自己的业务去调整。哪怕你最后只会用到单线程版本亲手实现一遍也会让你在排查内存问题时变得更有底气。如果后续你想往更深处走可以继续研究 tcmalloc 的 thread cache 分配流程、jemalloc 的 arena 设计或者尝试给内存池增加变长支持每条路都很有嚼头。