在C++中，直接调用new和delete虽然写法简单，但底层通用分配器并不是为零碎的小对象设计的。每次分配都可能陷入内核态进行地址空间扩展，还要维护隐藏的头部信息和空闲链表，释放时又需要合并相邻块，这些成本在大量短生命周期对象场景下会迅速累积。内存池的思路正好相反：它不向操作系统频繁要内存，而是自己管理一块从系统那里一次性申请到的连续区域。程序需要对象时从池中取一个固定大小单元，用完再放回。由于整个过程只涉及指针移动，不需要系统调用，也不需要搜索合适大小的空闲块，分配效率可以大幅提升。
内存池究竟解决了哪些性能瓶颈
通用内存分配器通常会在每块内存前面加上一小段元数据，用于记录块大小、前后块指针以及是否空闲等信息。对于小块对象来说，这些额外开销占比相当高，导致内存有效利用率下降。更重要的是，分配和释放算法需要遍历空闲块列表，当内存碎片较多时，这个遍历过程会变得不可预测。内存池将所有单元切成相同大小，空闲单元直接串成链表，分配时只取链表头节点，释放时只把节点重新挂回链表头，时间复杂度稳定为O(1)，不受当前内存碎片状况影响。
另一个不容忽视的问题是内存碎片。假设程序先后分配了若干不同大小的对象，释放其中一部分后，空闲内存被分割成许多不连续的小块，即使空闲总量足够，也可能无法满足一个较大对象的分配请求。固定大小内存池几乎不会产生这种外部碎片，因为池内单元大小一致，唯一可能浪费的是对象实际占用远小于单元大小时产生的内部碎片。这部分可以通过合理设置单元大小来缓解。
缓存局部性也是内存池带来的隐性收益。通用分配器可能把同一批创建的对象分配在相距很远的内存地址上，CPU缓存难以命中。内存池使用连续内存段，相邻对象大概率落在同一个缓存行或附近地址，访问效率更高。对于实时系统或高频交易、游戏引擎等对延迟敏感的场景，这种确定性分配行为比理论上的平均性能更有意义。
基础固定大小内存池的实现
实现一个最简内存池，只需要维护一个空闲链表指针和一块连续内存。每个空闲单元的前几个字节用来存储下一个空闲单元的地址，这样所有空闲单元就串成了一个单向链表。分配时返回链表头指针，并让链表头指向下一个节点；释放时把该单元作为新头节点，原来的头节点地址写入这个单元的前几个字节。可以用void**指针完成节点间地址的读写。
#include <cstddef>
#include <cstdlib>
#include <new>
class FixedMemoryPool {
public:
FixedMemoryPool(size_t blockSize, size_t blockCount)
: blockSize_(blockSize < sizeof(void*) ? sizeof(void*) : blockSize),
blockCount_(blockCount),
memory_(nullptr),
freeList_(nullptr) {
memory_ = static_cast<char*>(std::malloc(blockSize_ * blockCount_));
if (memory_ == nullptr) {
throw std::bad_alloc();
}
buildFreeList(memory_, blockCount_);
}
~FixedMemoryPool() {
std::free(memory_);
}
void* allocate() {
if (freeList_ == nullptr) {
return nullptr;
}
void* result = freeList_;
freeList_ = *reinterpret_cast<void**>(freeList_);
return result;
}
void deallocate(void* ptr) {
if (ptr == nullptr) {
return;
}
*reinterpret_cast<void**>(ptr) = freeList_;
freeList_ = ptr;
}
private:
void buildFreeList(char* memory, size_t count) {
freeList_ = memory;
char* current = memory;
for (size_t i = 0; i < count - 1; ++i) {
*reinterpret_cast<void**>(current) = current + blockSize_;
current += blockSize_;
}
*reinterpret_cast<void**>(current) = nullptr;
}
size_t blockSize_;
size_t blockCount_;
char* memory_;
void* freeList_;
};上面的实现把每个空闲单元的前sizeof(void*)个字节当作链表指针使用。为了确保任何对象指针都能存放在这些字节中，blockSize_在构造时被对齐到至少sizeof(void*)。分配函数从freeList_取出当前节点后，将链表头更新为该节点内保存的下一个地址。释放函数则把当前节点写入待释放单元，再让freeList_指向它，完成头插操作。整个过程没有调用malloc或free，只涉及指针赋值。
不过这个基础版本存在两个明显缺陷。第一，如果池内单元全部被分配出去，allocate直接返回nullptr，调用方必须处理分配失败，使用起来不够自然。第二，它只维护一块内存，当对象数量超过初始容量时无法自动扩展。因此在实际项目中，通常需要加入动态扩容机制，让池在空闲链表耗尽时主动申请新的内存块。
动态扩容与线程安全改进
为了支持扩容，可以用一个容器保存每次申请到的内存块地址，这样析构时就能逐个释放。当freeList_为空时，调用内部addBlock函数申请一块新的连续内存，把新块的单元逐一挂入空闲链表，并将链表头指向新块。这样可以保证池在运行期间始终能提供新单元，而不会频繁触发系统分配。
#include <cstddef>
#include <cstdlib>
#include <vector>
#include <mutex>
#include <new>
class ThreadSafeMemoryPool {
public:
ThreadSafeMemoryPool(size_t blockSize, size_t initialCount)
: blockSize_(blockSize < sizeof(void*) ? sizeof(void*) : blockSize),
blockCount_(initialCount),
freeList_(nullptr) {
addBlock(blockCount_);
}
~ThreadSafeMemoryPool() {
for (char* memory : blocks_) {
std::free(memory);
}
}
void* allocate() {
std::lock_guard<std::mutex> lock(mutex_);
if (freeList_ == nullptr) {
addBlock(blockCount_);
}
void* result = freeList_;
freeList_ = *reinterpret_cast<void**>(freeList_);
return result;
}
void deallocate(void* ptr) {
if (ptr == nullptr) {
return;
}
std::lock_guard<std::mutex> lock(mutex_);
*reinterpret_cast<void**>(ptr) = freeList_;
freeList_ = ptr;
}
private:
void addBlock(size_t count) {
char* memory = static_cast<char*>(std::malloc(blockSize_ * count));
if (memory == nullptr) {
throw std::bad_alloc();
}
blocks_.push_back(memory);
char* current = memory;
for (size_t i = 0; i < count - 1; ++i) {
*reinterpret_cast<void**>(current) = current + blockSize_;
current += blockSize_;
}
*reinterpret_cast<void**>(current) = freeList_;
freeList_ = memory;
}
size_t blockSize_;
size_t blockCount_;
void* freeList_;
std::vector<char*> blocks_;
std::mutex mutex_;
};这个版本通过std::mutex给分配和释放函数加锁，保证多线程环境下对freeList_的修改是安全的。加锁的方式实现简单，但在锁竞争激烈时可能成为性能瓶颈。对于只在线程本地频繁分配的场景，可以考虑每个线程维护自己的空闲链表，当本地链表耗尽时再从全局池批量获取一批单元，这样能把锁的粒度降到很低。
扩容策略也需要仔细权衡。如果每次只申请一个很小的块，那么系统调用次数会重新变多，失去内存池的意义；如果一次申请过大的块，又可能浪费物理内存。通常可以根据预估的对象峰值数量设置初始容量，并让每次扩容时申请与初始容量相同大小的块，或者采用倍增策略，让一次扩容后的总量翻倍。不同策略会直接影响内存占用和分配延迟，需要结合具体业务压力进行测试。
适用场景与使用注意事项
固定大小内存池最擅长处理对象大小相同、创建和销毁非常频繁的场景。例如网络服务器中每个连接都需要分配缓冲区，数据库连接池中每个连接对象结构固定，游戏引擎中的粒子系统每帧都会生成大量粒子对象。这些场景下使用内存池，可以减少系统调用次数，避免内存碎片，让对象创建和销毁的时间保持在纳秒级。
如果对象大小差异很大，或者生命周期极不规律，固定大小内存池的优势就会打折扣。内部碎片可能高到难以接受，因为池单元大小必须按照最大对象来设置，小对象也会占用同样大的空间。此时更适合使用对象大小相近的多个池，或者使用支持多尺寸分配的内存池变体，甚至直接依赖C++17引入的标准多态内存资源std::pmr::polymorphic_allocator。
使用内存池时还需特别关注调试难度。由于池中的内存不会真正返回给操作系统，某些内存泄漏检测工具可能无法准确识别未归还单元。最好在析构函数中统计剩余未释放单元数量，或在调试版本中加入额外校验。另一个常见问题是对象析构函数不会被自动调用，内存池只负责原始内存的复用，调用方必须手动执行析构逻辑，否则可能泄漏对象持有的资源。
总之，自实现内存池并不复杂，却能给高频分配场景带来数量级的性能提升。对大多数项目而言，先实现一个简单的固定大小内存池，再根据实际压测结果逐步加入扩容、线程安全和调试统计能力，是性价比较高的路线。若项目依赖C++17及以上标准，也可以基于std::pmr组件构建自定义内存资源，以获得更好的标准库兼容性。