说实话，我第一次认真看内存池，不是因为什么高大上的架构设计，而是被一张火焰图逼的。某项目的服务端在压测时 QPS 刚到预期的一半，CPU 就先满了，采样下来operator new和它底下的分配路径加起来占了将近三成。当时第一反应是"是不是哪里泄漏了"，查了半天没有，纯粹是分配太频繁——每个请求要构造几十个短生命周期的小对象，分配、释放、再分配，标准分配器在这条路径上做的加锁、查找合适空闲块、合并碎片这些活儿，累积起来就是实打实的开销。后来把一个核心结构换成了定长内存池，这条路径的开销直接掉了一个数量级。这篇就把我理解的内存池原理和一套能直接用的C++ 内存池实现完整摊开讲，从"为什么需要"到"怎么写出一个不出事的版本"，包括那些文档里不会写、只有自己踩过才知道的坑。适合已经会写 C++、但对底层分配机制还没系统梳理过的同学，也适合正在做性能优化的朋友直接抄结构。
1. 先搞清楚内存池到底在解决什么问题
1.1 从一次压测说起：分配开销藏在哪
很多人对new的成本有个误解，觉得它就是个指针加法。实际上一次普通的new，标准分配器要做的事情远比想象中多：先在当前线程的缓存里找合适大小的空闲块，找不到就去中央空闲链表找，再找不到就向操作系统要新的内存页；拿到块之后还要切分、写块头元信息；delete时要做反向的合并、归还。这一整套流程为了应对"任意大小、任意顺序、跨线程"的通用场景，付出了大量的分支判断和同步代价。
而绝大多数业务的真实情况是：同一类对象大小固定，生命周期短，分配释放极其频繁。用一个为"通用"设计的分配器去服务"极其特化"的场景，中间那些通用性开销全是浪费。这就是内存池的立足点——把通用问题特化成专用问题，用场景假设换性能。
我在那次优化里做过一个粗略的量化：单次分配释放的耗时从百纳秒级降到十几纳秒级，看着不多，但单请求 200 次分配、每秒 5 万请求的量级下，一秒钟省下来的就是毫秒级的 CPU 时间，摊到多核上就是实打实的吞吐提升。这类优化不惊艳，但极其稳定，而且一旦做好，后面所有同类结构都能复用。
1.2 内存池的本质：批发与零售的差别
用生活场景类比最容易理解。标准分配器像便利店，你每次要一点东西就跑去买一次，好处是灵活，什么都能买到，坏处是每次都要走一遍完整流程。内存池像批发商，一次性进一大批货囤在仓库里，之后谁来要就直接从仓库拿，流程被压缩成"从链表上摘一个节点"。
具体到实现上，内存池做了三件事来消除开销：
- 一次性大块申请：向系统要内存的动作从"每次分配"变成"每 N 次分配"，均摊成本被稀释到可以忽略。
- 预先切分成固定大小：切分工作在扩容时一次做完，分配阶段不再需要查找"哪个空闲块够大"这种逻辑，直接取链表头。
- 空闲块复用，不还给系统：释放只是把块挂回链表，不触发合并、不触发系统调用，代价恒定。
对应的代价也很明确：内存会被池长期占着，哪怕业务低谷期不用；只适合固定大小的分配，大小混杂的场景需要更复杂的结构；自己管理生命周期，写错了就是内存错误，调试成本比普通new高得多。这三条代价决定了它不是无脑上，得看场景。
1.3 什么场景该用、什么场景别碰
我一般用一个简单的判断表来过滤，避免过度设计：
| 判断维度 | 适合用内存池 | 不建议用内存池 |
|---|---|---|
| 对象大小 | 固定或集中在少数几档 | 大小跨度极大且随机 |
| 生命周期 | 短，创建销毁频繁 | 长，几乎不释放 |
| 分配频率 | 高频，是热点路径 | 低频，一天几次 |
| 数量规模 | 可预估上限 | 数量无界且波动剧烈 |
| 团队维护成本 | 有明确的封装边界 | 散落各处难以统一管理 |
举个具体的：网络服务里的连接对象、协议解析出来的消息节点、渲染循环里每帧生成的小结构，这些都是典型适用场景。反过来，一次性加载的大文件缓冲区、初始化阶段构建的配置树，用一个内存池去管它们，收益接近于零，反而多了一层理解成本。
注意：内存池不是"性能优化开关"，它是一个用内存占用和实现复杂度换分配速度的取舍。如果火焰图上分配路径压根进不了前几名，把时间花在别处回报更高。
还有一类容易忽略的情况：如果你的对象确实大小固定，但生命周期跨越了线程边界（A 线程创建、B 线程销毁），那单线程版内存池会直接崩。这种情况要么加锁，要么改成每个线程独立池加跨线程归还队列，复杂度会上一个台阶。
2. 设计前的几个关键决策
2.1 定长还是变长：先把最窄的一刀切下去
内存池按灵活度大致分三档：定长池、分级定长池（多个定长池按大小档位组合）、真正的变长分配器。第三档基本等同于自己重写一个通用分配器，需要处理块切分、相邻块合并、外部碎片，工作量和出错概率都远超一般业务的需要。
我的实践结论是：先用定长池吃掉 80% 的热点，剩下的再单独看。绝大多数性能问题的分配点都高度集中，把最热的那个结构池化，收益就已经足够了。定长池的代码量可以控制在一百多行，理解成本低，出问题也容易定位，这才是它能长期存在于生产代码里的前提。
如果想一步步演进，路径大概是：先做一个只服务单一类型的定长池模板，跑通之后再抽成通用的FixedSizeMemoryPool，最后再套一层对象池封装把构造析构也管起来。不要一上来就设计多档分级，那通常意味着你还没搞清楚真实的大小分布。
2.2 内存从哪来：三种取内存方式的取舍
池子里的"大块内存"从哪申请，这个决策会影响到后面的对齐和释放处理：
malloc/::operator new：最省事，拿到的内存保证满足max_align_t对齐，释放时配套调用即可。缺点是它自己也有开销，但因为你是一次申请一大块，这点开销被分摊掉了。new char[]：本质也是走operator new[]，行为接近上一条，但要注意必须用delete[]配平，别和operator delete混用。- 系统级页分配接口：直接按页申请，控制力最强，但跨平台差异明显，还要自己处理页对齐。除非你在写分配器本身，否则没必要。
我基本只用第一种，理由很实在：池子的价值在于减少调用次数，而不是减少单次调用的成本。只要调用次数降下来，单次走::operator new完全可接受。而且它天然的对齐保证省掉了一大堆麻烦——如果自己用new char[]再手动偏移，很容易把对齐搞坏，后面访问double或 SIMD 类型时就会出现只在特定平台上崩的诡异问题。
2.3 对齐这件事，比你想的重要
这是我最想强调的一条。池子把大块内存切成小块时，每一小块的起始地址必须是对齐的，否则你在上面构造任何有对齐要求的类型，都属于未定义行为。在 x86 上可能只是慢一点或者碰巧能跑，换到某些 ARM 平台上就是总线错误。
对齐要处理两个地方：
- 单块大小归一化：把请求的块大小向上取整到对齐粒度。假设对齐粒度是 16 字节，你请求 40 字节，实际给 48 字节。
- 切分起点对齐：大块内存的头部要放链表指针，这个头部的长度必须补齐到对齐粒度，否则第一块的起始地址就歪了，后面每一块都跟着歪。
第二点是最容易漏的。头部就一个指针，8 字节，看着没问题，但如果你把块大小设成 16 的倍数，数据区起点就是raw + 8，整体偏移 8 字节，全部块都变成 8 字节对齐。这个坑我在一个涉及double数组的结构上踩过，现象是某台机器上数值偶尔算错，查了两天才定位到。
2.4 用不用 placement new：分配与构造解耦
C++ 里"分配内存"和"构造对象"是两件事，new表达式把两件合并了，而 placement new 允许你在已有内存上单独做构造。内存池天然应该走分离路线：池子只负责给出一块原始内存，构造交给 placement new，析构显式调用。
这样做的好处是池子完全不需要知道对象类型，一个void*进一个void*出，通用性最强。同时它也让"内存复用但不重复构造"成为可能——比如某些结构构造代价高，你可以缓存已经构造好的实例，重置状态后直接复用，连构造函数都省了。这层优化在对象构造本身很重的时候，收益比省分配还大。
代价是你要自己保证构造和析构成对，不能漏调析构，否则对象持有的资源（比如内部指针、句柄）就泄漏了。这一点我会在对象池那一节用完整的封装来解决。
3. 手写一个定长内存池：从结构到代码
3.1 数据结构选型：为什么空闲链表要"嵌"在块里
空闲块的管理结构常见有两种：额外维护一个索引数组，或者把链表指针直接写进空闲块自己的内存里。后者叫嵌入式空闲链表，是我强烈推荐的做法。
原因很直接：零额外内存开销。索引数组要为每个块维护一个指针，如果有十万个块，那就是 800KB 的纯管理开销；嵌入式方式下，空闲块的那片内存本来就是闲置的，拿前 8 字节存个next指针不影响任何事。代价是块大小必须至少能放下一个指针，所以实际块大小有个下限，一般取sizeof(void*)或者更大一点。
结构上我定义两个东西：
struct FreeNode { FreeNode* next; // 仅当该块处于空闲状态时有效 }; struct Chunk { Chunk* next; // 指向下一批大块内存 };注意FreeNode只在块空闲时存在，一旦这块被分配出去，那 8 字节就归使用者了，池子不能再碰。这是嵌入式链表的核心约定，也是"分配出去的内存被池子写坏"这类 bug 的根源——只要你的代码里还有任何地方在块已分配的情况下访问node->next，就是悬垂写入。
3.2 核心代码：Allocate 与 Deallocate 的真实成本
先把完整骨架写出来，后面逐段解释：
#include <cstddef> #include <cstdint> #include <new> class FixedSizeMemoryPool { public: explicit FixedSizeMemoryPool(std::size_t blockSize, std::size_t initCount = 1024) : blockSize_(Normalize(blockSize)), blockCountPerChunk_(initCount), freeList_(nullptr), chunkList_(nullptr) { Expand(blockCountPerChunk_); } ~FixedSizeMemoryPool() { ReleaseAll(); } FixedSizeMemoryPool(const FixedSizeMemoryPool&) = delete; FixedSizeMemoryPool& operator=(const FixedSizeMemoryPool&) = delete; void* Allocate() { if (freeList_ == nullptr) { Expand(blockCountPerChunk_); // 按需扩容 } FreeNode* node = freeList_; freeList_ = node->next; return node; } void Deallocate(void* p) { if (p == nullptr) return; FreeNode* node = static_cast<FreeNode*>(p); node->next = freeList_; freeList_ = node; } private: static constexpr std::size_t kAlign = alignof(std::max_align_t); static std::size_t Normalize(std::size_t size) { if (size < sizeof(FreeNode)) size = sizeof(FreeNode); return (size + kAlign - 1) & ~(kAlign - 1); } static constexpr std::size_t AlignUp(std::size_t n) { return (n + kAlign - 1) & ~(kAlign - 1); } void Expand(std::size_t count); void ReleaseAll(); std::size_t blockSize_; std::size_t blockCountPerChunk_; FreeNode* freeList_; Chunk* chunkList_; };Allocate的整个路径就是：判空、取头、改头、返回。三条指令级别的工作，编译器优化之后基本就是一个 load 加两个 store。Deallocate更简单，把节点插到链表头。这就是它能比通用分配器快一个数量级的原因——不是它做了什么聪明的事，而是它把不必要的事全删了。
Normalize里两个动作都不能省：把小于指针大小的块抬到指针大小，避免写next时越界写坏相邻块；向上对齐到kAlign，保证每块起始地址满足最大基本对齐要求。
3.3 扩容实现：头部偏移这个坑必须处理
扩容负责的事情是：申请一大块原始内存，把前面留出头部区域，剩下的部分切成count块，全部挂到空闲链表上。
void FixedSizeMemoryPool::Expand(std::size_t count) { const std::size_t headerSize = AlignUp(sizeof(Chunk)); const std::size_t total = headerSize + blockSize_ * count; void* raw = ::operator new(total); Chunk* chunk = static_cast<Chunk*>(raw); chunk->next = chunkList_; chunkList_ = chunk; char* base = static_cast<char*>(raw) + headerSize; for (std::size_t i = 0; i < count; ++i) { FreeNode* node = reinterpret_cast<FreeNode*>(base + i * blockSize_); node->next = freeList_; freeList_ = node; } }关键在headerSize = AlignUp(sizeof(Chunk))这一句。Chunk本身只有一个指针，大小 8 字节，但raw是满足 16 字节对齐的，raw + 8就只有 8 字节对齐了。补齐到 16 之后，base重新回到 16 字节对齐，后面的每一块（因为blockSize_也是 16 的倍数）就都是对齐的。这一步省掉，写出来的内存池在简单用例上完全正常，遇到有对齐要求的类型就随机崩。
另外total直接按headerSize + blockSize_ * count申请，实际分配器会再向上取整到它自己的粒度，这部分浪费可以忽略。如果特别在意，可以在扩容时打印一下实际可用大小，不过一般没必要。
ReleaseAll就是把链上的大块逐个释放：
void FixedSizeMemoryPool::ReleaseAll() { Chunk* cur = chunkList_; while (cur) { Chunk* next = cur->next; ::operator delete(cur); cur = next; } chunkList_ = nullptr; freeList_ = nullptr; }这里有个顺序细节：必须在operator delete之前把next存下来，否则释放之后就再也找不到下一块了。这类低级错误写的时候觉得不可能犯，但在赶进度的时候真的会发生。
3.4 扩容策略与内存预算的计算过程
initCount怎么定，不是拍脑袋。我的做法是列三个数：
- 峰值并发块数：按最坏情况估算同时存活的块数量，比如每个连接持有一个节点、最大连接数 5000，那就是 5000 块。
- 单块实际字节：
blockSize_是归一化之后的，要按归一化值算，不是你请求的值。请求 40 字节、对齐 16，实际是 48 字节，多出 20%。 - 头部与碎片余量：按 110% 到 120% 估，主要吃掉扩容时的头部开销和对齐浪费。
算例：5000 块 × 48 字节 ≈ 240KB，加 20% 余量 ≈ 288KB。这个量级对服务端进程来说完全可以接受，而且它是一次性占用的稳态内存，不会继续涨。我一般把初始容量设成峰值的三分之一到一半，让扩容在启动后不久发生一两次就停下，避免运行期频繁扩容带来的抖动。
扩容时还有一个陷阱：不要在扩容时一次性把链表顺序反过来。有些实现为了优雅会用递归或者头插导致顺序反转，这本身无害，但如果你在调试时依赖"相邻块地址连续"这个假设去定位问题，反转会让你困惑半天。我的建议是扩容后的块按地址升序串接，调试时看地址一眼就知道属于哪一批。
3.5 一组对比数据：值不值得做
我在一台普通开发机上用chrono做了组简单对比，测试内容是 1000 万次"分配 + 立即释放 + 写一个字节"，重复了几轮取中间值。这类测试噪音不小，看量级就够了：
| 方案 | 单次操作耗时（约） | 相对开销 | 备注 |
|---|---|---|---|
new/delete | 60~110 ns | 1.0 | 受分配器实现和负载影响大 |
| 定长池 | 8~15 ns | 约 1/7 | 数据全在缓存内 |
| 对象池（含构造析构） | 20~40 ns | 约 1/3 | 构造本身有成本 |
这里的绝对值不要当真，不同机器差好几倍，重点看比例。还有一个更有意义的观察：池子的耗时分布非常集中，而new的耗时会出现明显的长尾，偶尔冒出一个几微秒的样本。对延迟敏感的服务来说，尾延迟的改善往往比平均值更有价值。
换算成实际收益：假设某接口每秒触发 50 万次分配，每次省 80ns，一秒就是 40ms 的 CPU 时间。单核看是 4%，但在一台跑满的机器上，4% 的 CPU 往往就决定了能不能扛住下一波流量。
4. 进阶用法：把池挂到对象生命周期上
4.1 重载类内 operator new：改动最小的接入方式
如果不想大改现有代码，最简单的方式是给类型重载operator new/operator delete，让这个类型的分配自动走池子，业务代码一行不用动：
class MessageNode { public: static void* operator new(std::size_t size) { if (size != sizeof(MessageNode)) { // 派生类会传更大的 size，安全兜底走系统分配 return ::operator new(size); } return Pool().Allocate(); } static void operator delete(void* p) { if (p == nullptr) return; Pool().Deallocate(p); } private: static FixedSizeMemoryPool& Pool() { static FixedSizeMemoryPool pool(sizeof(MessageNode), 1024); return pool; } // ... 成员 };那个size != sizeof(MessageNode)的判断一定要留。原因：如果这个类被继承，派生类的new会调用基类这个重载并传入派生类的大小，此时池子的块大小不够用，直接返回就是把对象写到别人的内存里。这条在单继承、多继承下都可能触发，而且测试环境经常覆盖不到。我现在的习惯是：类内重载 operator new 的类，直接禁止被继承，从源头上消除这个风险。
还有一个坑：operator new[]和operator new是两个不同的函数，如果类里只重载了前者而业务代码用了new Type[n]，会走全局版本，分配和释放路径不一致。要么两个都重载，要么明确约定这个类型不用数组形式。
4.2 线程安全：三种方案与各自的代价
上面写的版本是单线程的，两个线程同时Allocate会直接把链表搞坏，而且这种破坏往往延迟暴露，现象是隔几分钟随机崩一次。三种处理方式：
方案一：加自旋锁。最简单，代码里塞个原子标志位就行。代价是竞争激烈时性能反而不如通用分配器，因为它把所有的分配都串行化了。适合分配频率不高但确实跨线程的场景。
class SpinLock { public: void Lock() { while (flag_.exchange(true, std::memory_order_acquire)) { while (flag_.load(std::memory_order_relaxed)) { /* 空转 */ } } } void Unlock() { flag_.store(false, std::memory_order_release); } private: std::atomic<bool> flag_{false}; };方案二：线程本地池。用thread_local给每个线程一个独立池，完全无竞争，速度最快。但内存会按线程数翻倍，且跨线程释放会出错——A 线程分配的块在 B 线程释放，会挂进 B 的链表，虽然不一定立刻崩，但那条块的归属就乱了，A 线程下次扩容还会额外申请，内存只涨不降。
方案三：本地池 + 跨线程归还队列。每个线程有自己的池，释放时判断块归属，不属于本线程就压进一个无锁队列，由归属线程定期回收。这是生产级的做法，但代码量翻了好几倍，还得处理队列满了怎么办。
我的建议是按实际访问模式选：如果对象基本是"谁创建谁销毁"，thread_local就够了，这是性价比最高的；确实存在跨线程传递，就得做方案三，别用方案一去硬扛高并发。
// 用法上非常轻 thread_local FixedSizeMemoryPool tlsPool(sizeof(MessageNode), 256); void* MessageNode::operator new(std::size_t size) { return tlsPool.Allocate(); }thread_local有个隐蔽的坑：它的析构时机在部分编译器上是不确定的，如果某个全局对象的析构函数里还去访问thread_local池，可能访问到已经销毁的对象。我的做法是让池的析构函数只做"标记已销毁"，检测到已销毁就直接返回系统分配，宁可泄露也不要在退出阶段崩。
4.3 对象池封装：连构造析构一起管起来
池子只管字节，业务代码要反复写 placement new 和显式析构，很容易漏。包一层模板可以把这层收掉：
template <typename T> class ObjectPool { public: explicit ObjectPool(std::size_t initCount = 256) : pool_(sizeof(T), initCount) {} template <typename... Args> T* Create(Args&&... args) { void* mem = pool_.Allocate(); try { return new (mem) T(std::forward<Args>(args)...); } catch (...) { pool_.Deallocate(mem); // 构造抛异常，内存必须还回去 throw; } } void Destroy(T* p) { if (p == nullptr) return; p->~T(); pool_.Deallocate(p); } private: FixedSizeMemoryPool pool_; };那段try/catch是必须的。构造函数抛异常时，编译器会自动清理已构造的成员，但池子里的内存已经被摘出去了，没人还回来，结果就是每次构造失败漏一块。这类泄漏最难查，因为触发条件罕见，跑一晚上都不一定复现一次。
另一种更激进的用法是缓存已构造对象，重置状态后复用，连构造都省了。这需要类型提供一个Reset()语义的方法，而且要求状态完全可重置。好处是省掉了构造析构这一对开销，在某些构造很重的类型上收益明显；坏处是状态残留导致的问题非常隐蔽，我会额外在调试版本里加一段"重置后字段必须为默认值"的断言。
5. 踩坑实录与排查手册
5.1 常见问题速查表
下面这些是我和周围同事真实遇到过的，按现象归类，方便对号入座：
| 现象 | 可能原因 | 排查方向 |
|---|---|---|
| 随机崩溃，地址指向池内 | 块的next在被分配期间被写坏 | 检查是否有代码在已分配块上写前 8 字节 |
| 数据莫名被覆盖 | 块大小小于实际对象大小 | 核对sizeof(T)与池初始化参数 |
| 在某些平台上算错浮点 | 块起始地址未对齐 | 检查头部是否补齐到对齐粒度 |
| 内存持续增长不回落 | 池不归还系统，或跨线程释放 | 统计各线程池容量，检查归还路径 |
| 空闲链表成环，分配死循环 | 同一块被释放两次 | 加释放计数器，或调试期打标记位 |
| 程序退出时崩溃 | 静态池析构早于使用者 | 检查全局对象与静态局部变量的析构顺序 |
| 性能反而变差 | 加锁竞争激烈 | 看是不是所有分配都串行化了 |
我把"同一块被释放两次"放在这里单独提，因为它的后果特别恶劣：链表成环之后，Allocate会不断返回同一块地址，业务上表现为两个不同对象共用一片内存，数据互相覆盖，而崩溃点可能在很远的地方。排查办法是在块的头部预留一个标记字节，分配时置为一个魔数，释放时校验，不一致就立即断言。这个检查 debug 版本常开，release 版本关掉，几乎不影响性能。
5.2 三个最容易踩的实现细节
第一，直接释放非池内存。池子只能接收自己分配出去的指针。如果业务代码里某个对象一半从池里来、一半走普通new，然后统一在析构时还给池，那就直接崩。规避方式很笨但有效：给池分配出来的块都打上归属标记（比如在块尾留一个魔数），Deallocate时校验，不通过就直接跳过并记录日志。多花几个字节，换来的是崩溃变警告。
第二，复用块时忘了调析构。这是对象池引入之后最常见的问题。Destroy里一定要先p->~T()再还内存，顺序反了就是典型的使用后释放。有的类型析构里会释放内部持有的资源，漏调一次就是一次资源泄漏，现象是运行几天后句柄数打满。
第三，扩容后在旧指针上做地址比较。有些人喜欢用地址判断两个对象是否相邻，或者用地址做哈希。池子扩容会换一批大块内存，地址关系完全变了。这类代码在测试环境（只有一次扩容）通常正常，上生产（多次扩容）才暴露。
5.3 调试技巧：让池子自己说话
内存池出问题时最难的是"看不见"。我一般会在调试版本里加三样东西，成本很低但定位效率提升明显：
- 哨兵填充：分配时把整块内存填成
0xCD，释放时填成0xDD。崩溃时看内存内容，未初始化的0xCD和被释放后的0xDD一眼就能区分，很多"用了已释放内存"的问题就这么现形了。 - 统计钩子：记录累计分配次数、当前在用块数、扩容次数、峰值块数。这四个数在性能测试时特别有用——在用块数一直涨说明有泄漏，扩容次数超出预期说明初始容量估小了。
- 块头魔数：每块前面（或者复用
FreeNode的那 8 字节）写一个固定值，分配出去前置为该值，分配时校验。这个检查几乎零成本，但能第一时间抓住越界写。
再加一条我个人的习惯：给池提供一个Dump()接口，打印各批大块的首地址和容量，以及在用块数。线上出问题时，光看这几个数字就能判断是"池子太小导致频繁扩容"还是"有对象没释放"。
提示：这些调试设施一定要用编译期开关包起来（比如
#ifdef POOL_DEBUG），不要用运行期标志位。运行期标志位会让编译器没法优化掉填充逻辑，release 版本也会带上这份开销，性能测试的数据就不准了。
5.4 什么时候该停下：边界与替代方案
写到这里得说句实在话：定长池解决的是"单一类型高频分配"，如果你的场景是大量不同大小的对象随机分配释放，自己写变长池的投入产出比通常很差，那种情况应该去看成熟的多线程分配器实现思路，那些方案已经是几十年打磨的结果。自己动手的价值在于理解原理，以及在特定热点上做极致优化，而不是重造一个通用分配器。
另一个边界是内存占用。池子把内存攥在手里不还，如果你的服务有明显的波峰波谷，波峰过后内存不回落，可能触发监控告警。处理办法是给池加一个"收缩"接口，在用块数为零且持续一段时间后释放部分大块。但这会引入复杂度，而且收缩判断本身有成本，我的做法是先不做收缩，而是把初始容量估准，绝大多数场景下容量估准了根本不需要收缩。
6. 我在这套东西上积累的几点体感
回过头看，内存池这件事最值得说的不是代码，而是判断力：知道什么时候该写，什么时候不该写。我见过把整个项目所有new都替换成池的改法，结果内存占用翻了三倍，收益却测不出来，最后又回滚。也见过只在一个结构体上用了五十行代码，直接把一个接口的 P99 拉下来一大截。
如果你准备动手，我的顺序建议是：先用性能工具确认分配确实是热点，再统计这个热点对应类型的实际大小分布，然后只给最大的那一档建池，跑一轮压测对比数据，确认有效再推广。每一步都有数据支撑，比一次性设计一个完美方案要靠谱得多。
还有一点是我个人踩出来的：池子一定要有明确的归属边界。代码里最怕的就是"有些对象走池、有些不走"，然后某个地方把两边混着释放。我现在会在类型层面强制——一个类型要么全程走池（重载operator new且禁止继承），要么完全不走，不留中间态。这条规矩看着死板，但它把一整类难以复现的内存错误从可能性里删掉了。
最后分享一个小习惯：每次写这类底层结构，我都会先写一个二十行的迷你测试，模拟"分配一千次、随机释放一半、再分配两千次"这样的操作序列，配合哨兵填充跑一遍。这套测试五分钟能写完，但它抓住的问题比我事后调试的总时间成本要低得多。底层代码的调试成本从来不在写，而在找。
