C++高性能内存池实现：固定块与空闲链表设计详解

1. 项目概述：为什么我们需要自己造一个内存池？

在C++的世界里，尤其是高性能计算、游戏引擎、高频交易这些对延迟和吞吐量有极致要求的领域，new和delete（或malloc和free）这两个看似简单的操作，往往会成为性能瓶颈的“隐形杀手”。你可能在压测时发现，CPU使用率不高，但程序就是跑不快，一查性能分析工具，大量的时间都花在了内存分配和释放上。这就是我们今天要深入探讨的“内存池”所要解决的核心问题。

标准库的内存管理是通用型的，它需要应对千变万化的分配请求：从几个字节到几个GB，从单线程到多线程。这种通用性带来了巨大的开销：每次分配可能涉及寻找合适的内存块、加锁保护全局堆、更新内部数据结构（如空闲链表）等。频繁的小块内存分配释放，会导致严重的内存碎片，降低缓存命中率，最终拖慢整个程序。

而内存池（Memory Pool）的设计哲学是“以空间换时间，以专用换高效”。它的核心思想是：预先从系统申请一大块连续内存，程序运行时，所有的内存分配和释放都在这一大块“池子”内部进行，完全绕过系统的通用内存管理器。这样做的好处是立竿见影的：分配和释放几乎是O(1)的时间复杂度，避免了系统调用的开销和锁竞争，极大地减少了内存碎片，使得内存访问模式更加缓存友好。

所以，当你的项目出现以下特征时，就该认真考虑引入或实现一个内存池了：1）需要频繁创建和销毁大量小型对象（如游戏中的粒子、网络数据包）；2）对性能有极致要求，不能容忍标准内存管理的波动；3）对象的大小固定或仅在几种固定尺寸之间变化。接下来，我将带你从设计思路到代码实现，完整地拆解一个高性能固定块内存池，这是最经典、应用最广的一种内存池形式。

2. 核心设计思路与架构拆解

一个健壮的高性能内存池，不能只是简单粗暴地malloc一大块内存然后手动划分。我们需要一个清晰的设计来管理它的生命周期、处理并发、并高效地分配回收。这里我们聚焦于“固定块内存池”（Fixed-Block Memory Pool），因为它原理清晰、性能极高，是很多复杂内存分配器的基础组件。

2.1 整体架构与核心组件

我们的内存池将包含以下几个核心部分：

1. 内存块（Memory Block）：这是池子管理的基本单位。我们不是直接分配用户请求的字节数，而是将池子划分为一个个大小相等的块（Block）。每个块的大小是固定的，比如64字节、128字节等。用户申请内存时，我们分配一个完整的块给他，即使他只用了一部分。
2. 空闲链表（Free List）：这是内存池的灵魂数据结构，用于高效追踪哪些块是可用的。我们利用“嵌入指针”技术：在每个空闲内存块的开头几个字节，存储下一个空闲块的地址。这样，所有空闲块就通过指针连接成了一个单链表。分配时，我们从链表头取出一个块；释放时，我们将块插回链表头。这个过程没有任何内存拷贝，只有指针操作。
3. 内存池本体（Memory Pool）：它负责向操作系统申请和释放大块原始内存（通常使用operator new[]或malloc），并将其划分为多个内存块。同时，它持有空闲链表的头指针。
4. 对齐考虑（Alignment）：现代CPU访问未对齐的内存地址会导致性能下降甚至崩溃。我们必须确保每个内存块的起始地址都满足一定的对齐要求（通常是8字节、16字节）。这需要在计算块大小和划分内存时精心设计。

2.2 为何选择固定块与空闲链表？

选择固定块主要是为了极致的分配速度。因为所有块大小相同，我们不需要像通用分配器那样去寻找一个“合适大小”的空闲块，消除了最耗时的“匹配”过程。虽然可能造成内部碎片（比如用户申请33字节，但我们给64字节的块），但在对象大小相对统一的场景下，这种浪费是可接受的，并且可以通过设计不同尺寸的多个内存池（即“分离适配”）来缓解。

选择空闲链表（尤其是嵌入指针式）的原因在于其无与伦比的简单与高效。

• 零额外内存开销：管理信息（指针）直接存储在空闲内存块里，不需要为管理数据结构（如位图、外部控制头）单独分配内存。
• O(1)时间复杂度：分配和释放都是操作链表头，仅需几次指针赋值。
• 缓存友好：连续分配出去的块，在物理地址上很可能也是接近的，这提高了CPU缓存命中率。

这种设计的代价是，一旦内存被分配给用户，我们就无法通过这块内存本身得知它属于哪个池子（因为用户数据覆盖了嵌入的指针）。因此，常见的做法是在释放时，要求用户将内存指针回传给同一个池子对象，由池子对象来管理回收。或者，更高级的实现会在池子开头存储一个“魔术数字”或池子句柄来验证。

3. 关键数据结构与接口设计详解

理论说完了，我们开始动手设计类和数据结构。一个好的接口设计应该简洁、明确、不易误用。

3.1MemoryBlock结构体

虽然我们叫它“结构体”，但它并不是一个真正的C++struct。它是一个逻辑概念。我们约定，对于一块空闲的内存，它的前sizeof(void*)个字节被当作一个指针来使用。我们可以用一个联合体（Union）来清晰地表达这种“一内存两用”的特性，但为了代码直观，我们通常在实现中直接进行指针强制转换。

// 这是一个逻辑示意图，并非实际定义的结构体 struct MemoryBlock { MemoryBlock* next; // 仅当块空闲时，此指针有效 // 紧随其后的是可用的内存空间（对于空闲块，这部分未被使用） };

实际上，在代码中，我们操作的就是void*或char*，并通过reinterpret_cast来将其视为MemoryBlock*以访问next指针。

3.2MemoryPool类接口设计

class MemoryPool { public: // 构造函数：指定每个块的大小、池中初始块的数量 explicit MemoryPool(size_t blockSize, size_t blockCount); // 析构函数：释放所有从系统申请的内存 ~MemoryPool(); // 禁止拷贝，允许移动（根据需求） MemoryPool(const MemoryPool&) = delete; MemoryPool& operator=(const MemoryPool&) = delete; MemoryPool(MemoryPool&&) noexcept; MemoryPool& operator=(MemoryPool&&) noexcept; // 核心接口：分配一块内存 void* allocate(); // 核心接口：释放一块由本池分配的内存 void deallocate(void* ptr); // 工具函数：获取块大小、总容量、空闲块数等 size_t getBlockSize() const { return _blockSize; } size_t getTotalBlocks() const { return _totalBlocks; } size_t getFreeBlocks() const { return _freeBlocks; } private: void* _memoryChunk = nullptr; // 指向从系统申请的大内存块 size_t _chunkSize = 0; // 大内存块的总字节数 size_t _blockSize = 0; // 每个内存块的字节数（对齐后） size_t _totalBlocks = 0; // 内存块总数 size_t _freeBlocks = 0; // 当前空闲块数 MemoryBlock* _freeList = nullptr; // 空闲链表头指针 // 内部初始化函数，用于在构造函数中构建空闲链表 void _initializePool(); };

接口设计要点解析：

1. explicit构造函数：防止隐式类型转换，要求调用者明确指定块大小和数量。
2. 删除拷贝构造和赋值：内存池通常独占其管理的内存，拷贝语义不明确且危险，所以直接禁止。移动语义则很有用，可以高效地转移资源所有权。
3. 简单的allocate/deallocate：不模仿operator new的size_t参数，因为我们是固定块池，调用者知道块大小。这简化了内部逻辑。
4. _freeList类型：使用MemoryBlock*能让代码意图更清晰，尽管底层我们操作的是原始内存。
5. 成员变量：_memoryChunk和_chunkSize用于管理原始内存的生命周期。_freeBlocks计数器可用于快速判断池是否已空，避免不必要的链表操作。

4. 逐步实现：从内存申请到链表构建

现在，我们深入构造函数和初始化过程的实现细节，这里充满了“坑”和技巧。

4.1 构造函数与内存对齐计算

MemoryPool::MemoryPool(size_t blockSize, size_t blockCount) { if (blockSize == 0 || blockCount == 0) { throw std::invalid_argument("Block size and count must be positive."); } // 1. 计算对齐后的块大小 // 我们需要确保每个块的大小是“对齐要求”的整数倍，并且能容纳一个指针。 // 常见的对齐要求是 alignof(std::max_align_t)，这里我们以8字节为例，并确保能放下指针。 const size_t alignment = 8; size_t pointerSize = sizeof(void*); // 对齐后块大小 = ceil((max(blockSize, pointerSize)) / alignment) * alignment size_t actualBlockSize = std::max(blockSize, pointerSize); if (actualBlockSize % alignment != 0) { actualBlockSize = ((actualBlockSize / alignment) + 1) * alignment; } _blockSize = actualBlockSize; // 2. 计算需要申请的总内存大小 // 总大小 = 块大小 * 块数量 // 注意：这里不需要为每个块额外添加“头信息”，因为我们的“头”（指针）是嵌入在空闲块中的。 _totalBlocks = blockCount; _chunkSize = _blockSize * _totalBlocks; // 3. 向系统申请大块连续内存 // 使用 operator new[] 保证内存是连续且未初始化的。 // 也可以使用 aligned_alloc 来直接申请对齐的内存，但为了兼容性，这里用 new。 _memoryChunk = static_cast<char*>(::operator new[](_chunkSize)); // 重要：初始化内存为0不是必须的，但有助于调试，防止野指针。 std::memset(_memoryChunk, 0, _chunkSize); // 4. 初始化空闲链表和计数器 _freeBlocks = _totalBlocks; _freeList = nullptr; _initializePool(); }

注意：对齐的陷阱。对齐计算是内存池正确运行的基石。如果块地址没有正确对齐，在某些架构（如ARM）上，用这个地址访问数据会导致总线错误（Bus Error）或严重的性能损失。我们上面的计算保证了每个块的起始地址都是alignment的倍数。更严谨的做法是使用alignof(std::max_align_t)作为默认对齐值，它代表了当前平台下任何标量类型所需的最大对齐。

4.2_initializePool：构建初始空闲链表

这是将一块原始内存“格式化”成我们池子的关键步骤。

void MemoryPool::_initializePool() { if (!_memoryChunk || _totalBlocks == 0) return; // 将第一块内存的地址作为链表头 _freeList = reinterpret_cast<MemoryBlock*>(_memoryChunk); // 遍历每一块内存，将其链接起来 MemoryBlock* current = _freeList; for (size_t i = 0; i < _totalBlocks - 1; ++i) { // 计算下一块内存的地址 char* nextBlockAddr = reinterpret_cast<char*>(current) + _blockSize; MemoryBlock* nextBlock = reinterpret_cast<MemoryBlock*>(nextBlockAddr); // 在当前块的头部（即这块内存的开始处）写入下一个块的地址 current->next = nextBlock; current = nextBlock; } // 最后一个块的 next 指针置为 nullptr，表示链表结束 current->next = nullptr; }

实现解析：

1. 类型转换：我们使用reinterpret_cast将char*转换为MemoryBlock*。这是因为我们在逻辑上把这块内存当作一个包含next指针的结构体来操作。这是C++中实现“侵入式链表”的常见手法。
2. 地址计算：nextBlockAddr = current地址 + _blockSize。这依赖于_memoryChunk是一块连续的内存，并且我们之前已经做好了对齐，所以这个加法能精准地指向下一个块的起始位置。
3. 构建链表：循环将第i块的next指向第i+1块，形成一个单链表。初始化后，_freeList指向第一个块，第一个块指向第二个，...，最后一个块指向nullptr。

实操心得：调试初始化。在_initializePool完成后，可以写一个简单的调试循环，遍历_freeList并打印每个块的地址，确保链表是连续的，并且没有越界。这能及早发现对齐或大小计算错误。

5. 核心分配与回收算法的实现

池子初始化好了，最核心的allocate和deallocate实现起来就非常简洁，这正是性能所在。

5.1allocate：从链表头弹出一个块

void* MemoryPool::allocate() { // 1. 检查池中是否还有空闲块 if (_freeList == nullptr) { // 池已空，可以在这里选择：抛出异常、返回nullptr、或向系统申请更多内存扩容。 // 这里我们选择返回nullptr，让调用者处理。 // throw std::bad_alloc(); // 另一种选择 return nullptr; } // 2. 从空闲链表头部获取一个块 MemoryBlock* allocatedBlock = _freeList; // 3. 将链表头指向下一个空闲块 _freeList = _freeList->next; // 4. 更新空闲块计数器 --_freeBlocks; // 5. 返回这块内存的地址（作为给用户的纯数据区） // 注意：返回的地址就是 allocatedBlock 本身。 // 对于用户来说，这是一块可用的、大小为 _blockSize 的内存。 // 但 allocatedBlock->next 的值现在对用户来说是垃圾数据，不过没关系，用户用不到。 return static_cast<void*>(allocatedBlock); }

性能分析：这个函数只有几次指针解引用、赋值和减法操作，没有任何循环或系统调用，是真正的O(1)操作。在多线程环境下，这里需要加锁（后面会讲），但即使加锁，临界区也非常小。

5.2deallocate：将块插回链表头

void MemoryPool::deallocate(void* ptr) { // 1. 安全检查：空指针直接返回 if (ptr == nullptr) { return; // C++标准规定 delete nullptr 是安全的，我们遵循此惯例。 } // 2. （可选）边界检查：确保 ptr 确实落在 _memoryChunk 管理的范围内。 // 这是一个重要的防御性编程措施，可以防止误还非本池内存。 char* cptr = static_cast<char*>(ptr); if (cptr < _memoryChunk || cptr >= _memoryChunk + _chunkSize) { // 通常记录日志或断言，这里简单返回或抛出异常。 // throw std::invalid_argument("Pointer does not belong to this memory pool."); return; // 或者直接忽略，但记录错误是更好的实践。 } // 3. （可选）对齐检查：确保 ptr 是 _blockSize 对齐的。 // 因为我们的块是对齐分配的，归还的地址也应该是对齐的。 if ((reinterpret_cast<uintptr_t>(ptr) % _blockSize) != 0) { // 地址不对齐，说明可能是一个损坏的指针。 // throw std::invalid_argument("Unaligned pointer for deallocation."); return; } // 4. 将用户指针转换回 MemoryBlock* 类型 MemoryBlock* blockToFree = reinterpret_cast<MemoryBlock*>(ptr); // 5. 将待释放的块插入空闲链表头部 blockToFree->next = _freeList; _freeList = blockToFree; // 6. 更新空闲块计数器 ++_freeBlocks; }

安全与健壮性解析：

1. 空指针处理：与C++标准行为保持一致，释放空指针是安全的无操作。
2. 边界检查：这是防止“野指针”或“错还指针”的关键。如果用户不小心把其他内存地址传进来，这个检查能大概率发现。但它不是100%可靠，因为指针可能恰好落在池子范围内但不是起始地址。更严格的检查可以结合“魔术数字”（在分配时写入一个特定值，释放时验证）。
3. 对齐检查：一个有效的池内指针必然是块大小的整数倍偏移。这个检查能过滤掉很多无效的中间地址。
4. 头插法：插入链表头部是最快的，也是O(1)。这可能导致分配顺序不是严格的FIFO，但对于缓存来说，最近释放的块很可能还在缓存中，下次分配它可能更快（局部性原理）。

注意事项：释放时的“use-after-free”陷阱。内存池将内存交还给空闲链表后，从用户角度看，这块内存已经“释放”了。但如果用户代码仍然持有该指针并访问它，将会读到链表指针数据（如果该块被重新链接）或未定义的数据，导致难以调试的bug。内存池无法解决这类逻辑错误，良好的编程习惯和使用智能指针或内存分析工具是关键。

6. 多线程安全：给内存池加上锁

我们上面实现的是一个单线程版本。在现代多核CPU上，要让内存池真正实用，必须考虑线程安全。最直接的方式是使用互斥锁（Mutex）。

6.1 线程安全版 MemoryPool

我们需要引入锁，并在allocate和deallocate操作前后加锁。

#include <mutex> class ThreadSafeMemoryPool { public: // ... 构造函数、析构函数等与之前类似 ... void* allocate() { std::lock_guard<std::mutex> lock(_mutex); // 加锁 // ... 原有的分配逻辑 ... if (_freeList == nullptr) return nullptr; MemoryBlock* block = _freeList; _freeList = _freeList->next; --_freeBlocks; return block; } // lock_guard 析构，自动解锁 void deallocate(void* ptr) { if (ptr == nullptr) return; // 边界检查和对齐检查可以放在锁外，因为它们不访问共享数据 char* cptr = static_cast<char*>(ptr); if (cptr < _memoryChunk || cptr >= _memoryChunk + _chunkSize) return; if ((reinterpret_cast<uintptr_t>(ptr) % _blockSize) != 0) return; std::lock_guard<std::mutex> lock(_mutex); // 加锁 MemoryBlock* block = reinterpret_cast<MemoryBlock*>(ptr); block->next = _freeList; _freeList = block; ++_freeBlocks; } // 自动解锁 private: std::mutex _mutex; // ... 其他成员变量 ... };

6.2 锁粒度优化与无锁探索

简单的全局锁虽然安全，但在极高并发下，锁竞争会成为瓶颈。我们可以考虑以下优化策略：

1. 线程本地存储（Thread-Local Storage, TLS）：每个线程拥有自己的小内存池。分配和释放绝大多数情况下都在线程本地无锁进行。只有当本地池为空或满时，才去访问一个全局的“中央池”进行批量交换。这能极大地减少竞争。这就是很多现代高性能内存分配器（如tcmalloc、jemalloc）的核心思想之一。
2. 无锁编程：使用原子操作（如std::atomic）来实现空闲链表的pop和push。这需要用到“比较并交换”（Compare-And-Swap, CAS）操作。实现一个正确的无锁栈（我们的空闲链表本质上是一个栈）是可能的，但代码复杂，且需要处理ABA问题（可以通过带标签的指针解决）。

   // 无锁分配的大致思路（伪代码） MemoryBlock* allocate() { MemoryBlock* oldHead = _freeList.load(std::memory_order_acquire); do { if (oldHead == nullptr) return nullptr; } while (!_freeList.compare_exchange_weak(oldHead, oldHead->next, std::memory_order_acq_rel, std::memory_order_acquire)); --_freeBlocks; // 注意：计数器也需要原子操作 return oldHead; }

   无锁实现性能可能更高，但开发、测试和调试难度极大，除非你对性能有极端要求且有足够的并发编程经验，否则建议从带锁版本开始，或者使用成熟的第三方库。

实操心得：性能测试与锁竞争。在实现多线程版本后，务必用压力测试工具（如多个线程循环分配释放）来验证其正确性和性能。使用性能分析工具查看锁的争用情况。如果_mutex的争用非常激烈，说明全局锁已成为瓶颈，就该考虑TLS或无锁方案了。

7. 高级话题：内存池的扩展、调试与集成

一个工业级的内存池还需要考虑更多问题。

7.1 内存不足处理与动态扩容

我们当前的实现在池空时直接返回nullptr。更友好的设计是支持动态扩容。

思路：当allocate()发现_freeList为空时，不是直接失败，而是触发一个扩容操作。

1. 向系统申请一块新的、更大的内存块（或另一块等大的内存块）。
2. 将这块新内存格式化为新的内存块，并链接到现有的空闲链表上。
3. 更新_memoryChunk（可能需要用指针数组管理多块内存）、_chunkSize和_totalBlocks。
4. 然后重新尝试分配。

挑战：

• 地址连续性：新申请的内存块和旧的不一定连续，这没关系，我们的空闲链表可以管理非连续的内存块。
• 释放问题：deallocate需要知道一个指针属于哪一块原始内存，以便进行边界检查。管理多个内存块需要更复杂的数据结构（如一个记录所有内存块起始地址和大小的表）。
• 锁的考虑：在扩容时，可能需要独占锁，因为它在修改池的整体结构。

7.2 调试与诊断支持

内存池隐藏了系统的内存管理，这给调试带来了困难。我们可以为内存池添加调试功能。

1. 魔术数字（Magic Number）：在分配时，在返回给用户的内存块尾部（或头部，如果不怕覆盖）写入一个特定的值（如0xDEADBEEF）。在释放时检查这个值。如果值被修改了，说明用户可能发生了缓冲区溢出。
2. 分配/释放日志：在调试版本中，记录每次分配和释放的地址、线程ID、时间戳，甚至调用栈（可用backtrace函数）。当发生内存泄漏或重复释放时，可以输出日志分析。
3. 内存填充：在分配时将内存填充为特定模式（如0xCD），在释放时填充为另一种模式（如0xDD）。这有助于在调试器中识别未初始化和已释放的内存。

7.3 与标准库和智能指针集成

为了让内存池用起来像标准new/delete一样自然，我们可以重载类的operator new和operator delete，或者使用“分配器（Allocator）”概念。

为特定类定制：

class MyObject { public: static MemoryPool s_pool; // 静态内存池 void* operator new(size_t size) { // 可以断言 size 是否符合预期 assert(size == sizeof(MyObject)); return s_pool.allocate(); } void operator delete(void* ptr) { s_pool.deallocate(ptr); } // ... 其他成员 ... }; MemoryPool MyObject::s_pool(sizeof(MyObject), 1000); // 初始化静态池

这样，使用new MyObject和delete obj就会自动走我们的内存池。

作为标准分配器： 我们可以让MemoryPool类满足C++标准库的Allocator概念（即提供allocate,deallocate,construct,destroy等类型定义和成员函数）。然后就可以用于std::vector,std::list等容器：

std::vector<MyObject, ThreadSafeMemoryPool<MyObject>> vec;

这需要更多的模板元编程知识，但能让内存池的应用范围更广。

8. 性能对比测试与常见问题排查

理论再好，也需要数据验证。我们来设计一个简单的性能测试，并总结常见问题。

8.1 简易性能测试方案

#include <chrono> #include <iostream> #include <vector> const int ITERATIONS = 1000000; const int OBJECT_SIZE = 64; const int POOL_CAPACITY = 10000; void testSystemAlloc() { std::vector<void*> ptrs; ptrs.reserve(ITERATIONS); auto start = std::chrono::high_resolution_clock::now(); for (int i = 0; i < ITERATIONS; ++i) { ptrs.push_back(::operator new(OBJECT_SIZE)); } for (void* ptr : ptrs) { ::operator delete(ptr); } auto end = std::chrono::high_resolution_clock::now(); auto duration = std::chrono::duration_cast<std::chrono::microseconds>(end - start); std::cout << "System new/delete: " << duration.count() << " us" << std::endl; } void testMemoryPool() { MemoryPool pool(OBJECT_SIZE, POOL_CAPACITY); std::vector<void*> ptrs; ptrs.reserve(ITERATIONS); auto start = std::chrono::high_resolution_clock::now(); for (int i = 0; i < ITERATIONS; ++i) { void* ptr = pool.allocate(); if (!ptr) { // 处理分配失败，这里简单重试（实际应扩容） --i; continue; } ptrs.push_back(ptr); } for (void* ptr : ptrs) { pool.deallocate(ptr); } auto end = std::chrono::high_resolution_clock::now(); auto duration = std::chrono::duration_cast<std::chrono::microseconds>(end - start); std::cout << "MemoryPool: " << duration.count() << " us" << std::endl; }

在我的测试环境（Linux g++）下，内存池的耗时通常只有系统分配的1/10甚至更少。差距在对象越小、分配越频繁时越明显。

8.2 常见问题排查速查表

8.3 我踩过的几个坑

1. 对齐计算错误：早期版本我忽略了指针本身的大小，如果用户请求的blockSize小于sizeof(void*)，那么嵌入的指针就会覆盖用户数据。所以必须保证actualBlockSize = max(blockSize, sizeof(void*))，然后再做对齐。
2. 多线程下的ABA问题：尝试实现无锁版本时，遇到了经典的ABA问题。线程T1读取链表头A，然后被挂起。T2弹出A，释放A，然后一个新分配恰好又返回了A（地址相同，但内容可能已被用户修改），并压回链表头。T1恢复后执行CAS，发现头还是A，就错误地成功了，但此时A->next可能已经不是一个有效的链表节点。解决方案是使用带标签的指针（将指针与一个递增的计数器打包成一个机器字进行CAS）。
3. 与STL容器混用的陷阱：如果你为自定义类重载了operator new/delete，但将这个类放入std::vector，vector在扩容时可能会使用::operator new来分配原始内存，而不是你的重载版本。要彻底接管，需要实现一个符合标准的分配器。

实现一个高性能内存池是一次对C++内存管理机制的深度探索。从清晰的设计思路，到严谨的对齐计算，再到高效的无锁链表操作，每一步都考验着我们对底层细节的掌控。虽然现代C++标准库提供了std::pmr::memory_resource等更现代化的内存管理工具，但亲手实现一遍内存池，对于理解内存分配的本质、提升性能调优和解决复杂问题的能力，仍然是无可替代的。建议你在理解这个固定块内存池的基础上，进一步尝试实现一个“分离适配”内存池，它能管理多种不同大小的块，向通用分配器又迈进了一步。