std::allocator不够用是因为每次allocate()都触发系统调用，导致高频小对象场景下开销大、碎片多、缓存不友好；自定义内存池通过预分配大块内存并用空闲链表切分复用，绕过系统调用，适用于大小固定的对象如游戏实体、网络包缓冲区等。
为什么直接用 std::allocator 不够用？
因为 std::allocator 每次调用 allocate() 都会触发系统级内存分配（比如 malloc 或 operator new），在高频小对象场景下开销大、碎片多、缓存不友好。自定义内存池的核心目标是：预分配一大块内存，再从中切出小块供反复复用，绕过频繁的系统调用。
典型适用场景包括：游戏实体组件、网络包缓冲区、高频创建销毁的节点类（如链表节点、树节点）。注意——这不是通用替换方案，仅适用于对象大小固定或有限几种规格的场景。
如何写一个固定大小的内存池分配器？
关键在于维护一个空闲块单链表：每次 allocate() 从链表头取一块，deallocate() 把块插回头部。不需要记录块大小，因为所有块等长。
- 用
char*管理底层内存，避免构造/析构干扰原始内存布局 - 空闲链表指针就藏在每块内存的开头（即“union free list pointer + payload”）
-
allocate()返回的是 payload 起始地址（跳过指针空间），deallocate()需把传入指针往回偏移 sizeof(void*) 才能恢复链表指针位置 - 必须显式提供
rebind模板别名（C++11 要求），否则容器无法适配其他类型
示例片段：
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
template<typename T>
class FixedPoolAllocator {
static constexpr size_t BLOCK_SIZE = sizeof(T);
char* pool_;
void* free_list_ = nullptr;
size_t pool_size_;
size_t block_count_;
<p>public:
using value_type = T;
template<typename U> struct rebind { using other = FixedPoolAllocator<U>; };</p><pre class='brush:php;toolbar:false;'>FixedPoolAllocator(size_t n = 128) : pool_size_(n * BLOCK_SIZE), block_count_(n) {
pool_ = new char[pool_size_];
// 构建空闲链表
for (size_t i = 0; i < block_count_; ++i) {
void* p = pool_ + i * BLOCK_SIZE;
*static_cast<void**>(p) = free_list_;
free_list_ = p;
}
}
T* allocate(size_t n) {
if (n != 1 || !free_list_) throw std::bad_alloc{};
void* p = free_list_;
free_list_ = *static_cast<void**>(p);
return static_cast<T*>(p);
}
void deallocate(T* p, size_t n) {
if (n != 1) return;
void* raw = p;
*static_cast<void**>(raw) = free_list_;
free_list_ = raw;
}};
使用时要注意哪些兼容性陷阱？
STL 容器对分配器有隐含假设，稍不注意就会崩溃或未定义行为：
-
std::vector可能调用allocate(0)，你的allocate()必须能处理n == 0（返回 nullptr 或任意合法指针） -
std::list和std::map在 C++17 前要求分配器可复制（copyable），所以成员不能含 non-copyable 资源（如独占std::unique_ptr<char[]>）；改用裸指针或std::shared_ptr更稳妥 - 不同类型的分配器实例默认不相等（
operator==返回 false），但某些容器（如std::vector的swap）要求相等性判断为 true 才能移动内存——需重载operator==和operator!=，通常返回true（表示“同构”即可） - 不要在分配器里做耗时操作（如加锁），否则会拖慢所有容器操作；线程安全应由上层控制
什么时候该放弃手写而用现成方案？
当需求超出单尺寸池范畴时——比如要支持多种对象大小、需要线程局部缓存（TLB）、或希望自动合并相邻空闲块——手写容易出错且维护成本陡增。此时优先考虑：boost::pool_allocator、folly::PooledObjectAllocator，或更底层的 malloc_usable_size + 自定义 operator new 全局重载。
另外，现代 libc（如 musl、glibc 2.34+）和 LLVM libcxx 对小对象已有优化，简单场景下可能比你写的池还快。实测前先用 perf 或 valgrind --tool=massif 确认确实是分配器瓶颈，而不是算法或数据结构问题。
