企业官网建设流程全解析

内存池这个东西，我在项目里手写过好几次，每次写完都觉得“这不就是个链表吗”，但每次深入调优的时候，又总能被各种边界问题打脸。网上讲内存池原理的文章很多，真正能落地、能处理多线程、能做内存对齐、能排查线上崩溃的实操内容反而少。这篇文章我就用一次完整的自定义实现经历，把从设计、编码、测试到踩坑的全过程拆开讲清楚。

如果你在写网络服务、游戏服务器、高频交易引擎，或者任何对分配延迟敏感的模块，又或者你只是好奇 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_cast<void**>(freeList_); ++allocatedCount_; return ptr; } void deallocate(void* ptr) { if (ptr == nullptr) return; *reinterpret_cast<void**>(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_cast<char*>(chunk)); char* p = static_cast<char*>(chunk); for (size_t i = 0; i < blockCount; ++i) { void** slot = reinterpret_cast<void**>(p); *slot = freeList_; freeList_ = slot; p += blockSize_; } freeCount_ += blockCount; } size_t blockSize_; void* freeList_ = nullptr; std::vector<char*> 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_cast<void**>(cache.localFreeList); ++cache.localAllocated; return ptr; } void deallocate(void* ptr) { auto& cache = getTlsCache(); *reinterpret_cast<void**>(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_guard<std::mutex> lock(globalMutex_); for (size_t i = 0; i < batchSize_; ++i) { void* ptr = pool_.allocate(); *reinterpret_cast<void**>(ptr) = cache.localFreeList; cache.localFreeList = ptr; ++got; } } cache.localBatch = got; } void releaseToGlobal(TLS& cache) { std::lock_guard<std::mutex> lock(globalMutex_); while (cache.localFreeList != nullptr) { void* next = *reinterpret_cast<void**>(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_cast<char*>(::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::atomic<size_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 至少要查空闲链表、做切分、更新元数据。不过要提醒一句：如果你的机器内存分配器本身已经做了很好的线程缓存优化（现代 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 和归还时才碰锁。

如果你不想过度设计，可以先试试 C++17 的std::mutex换成std::shared_mutex做读写锁，但这通常只是杯水车薪。分配和释放本质上都是写操作，读锁帮不上忙。

4.4 内存碎片与池扩缩容策略

还有一个经常被忽略的问题：内存池扩容后不会自动缩容。如果某次流量峰值导致池子扩到了 10 万块，之后流量回落到 1 万块，那 9 万块就会一直占着内存，不归还操作系统。

我一般留一个手动整理的接口，允许业务在低峰期调用compact()，把所有空闲 chunk 释放掉。实现方式是：遍历 chunks_ 列表，记录每个 chunk 里有多少空闲块，如果当前 chunk 的空闲比例达到 90% 以上，就把这个 chunk 整体归还给系统，并从池的 chunk 列表中移除。这个机制能有效防止内存池变成内存黑洞。

另外一个细节：池的初始化块数量最好根据业务对象的峰值并发量来估算。如果你知道系统同时最多存在 2 万个连接对象，池初始就开 2 万个块，避免运行时频繁扩容。扩容本身要分配一整块大内存，虽然不频繁，但一旦发生，延迟毛刺是躲不开的。

4.5 常见问题速查表

我把日常使用中遇到的高频问题整理成了一个表格，方便大家按图索骥：

4.6 有没有必要加 header 元数据

我见过有些内存池实现会在每个块的头部加一个 Header 结构，存块大小、魔数、池 ID 等元数据。这种做法会让内存池实现变简单（比如 deallocate 时能通过 header 判断归属），但是会付出两个代价：一是每块内存要多出 8 到 16 字节的头部开销，对于小对象这是不可接受的膨胀；二是分配出的指针不再对齐到块的起始地址，增加了对齐处理的复杂度。

我自己的偏好是：定长池不加 header，因为块信息本身可以从池对象推导出来；只有变长池或跨线程归还频繁的场景，才考虑加 header。加 header 的位置也有讲究，最好把 header 放在块内，而不是块前，这样分配出的指针天然对齐。块内 header 的意思是：块的可写区域从 offset=0 开始就是 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 设计，或者尝试给内存池增加变长支持，每条路都很有嚼头。