内存池的核心目标是“可控”而非“快”，专用于确定生命周期、固定大小对象的批量管理，需显式构造/析构、严格对齐、线程安全设计，禁用全局重载。
内存池的核心目标不是“快”，而是“可控”
直接用 new 和 delete 每次都走系统堆分配，会有碎片、锁争用、调用开销。内存池真正要解决的，是**确定生命周期的对象批量管理**——比如网络请求上下文、游戏实体组件、日志缓冲区。它不适用于生命周期差异大、大小不一且随机释放的场景。
常见误操作：把内存池做成万能替换 malloc 的黑盒。结果是对象析构顺序失控、operator delete 匹配失败、多线程下未加锁导致 free_list 链表断裂。
- 必须明确池中对象类型（通常为固定大小），否则无法做块对齐和快速索引
- 构造/析构必须显式调用：
new (ptr) T(args...)和ptr->~T()，不能依赖new T自动完成 - 若支持多线程，
allocate/deallocate内部至少需原子操作或细粒度锁，避免用全局互斥锁拖慢吞吐
重载类内 operator new 是最安全的起点
比起全局重载，为具体类定制更可控：语义清晰、不干扰第三方库、可配合 RAII 管理池生命周期。关键点在于：分配函数只管“给内存”，不调用构造；对应 operator delete 只回收，不调用析构。
class Packet {
static std::vector pool;
static std::stack free_list;
static std::mutex mtx;
public:
void operator new(size_t size) {
if (size != sizeof(Packet)) throw std::bad_alloc();
std::lock_guard lk(mtx);
if (!free_list.empty()) {
void ptr = free_list.top();
free_list.pop();
return ptr;
}
// fallback to malloc if pool exhausted
return malloc(size);
}
void operator delete(void* ptr, size_t size) noexcept {
if (!ptr) return;
if (size == sizeof(Packet)) {
std::lock_guard lk(mtx);
free_list.push(ptr);
} else {
free(ptr);
}
} };
立即学习“C++免费学习笔记（深入）”；
注意：operator delete 必须带 size_t 参数重载，否则 delete p; 会调用无参版本，导致内存没归还到池里。
全局 operator new 重载风险极高，慎用
除非你完全掌控整个二进制（无第三方动态库、无 STL 容器在池外分配），否则极易引发未定义行为。典型问题：
-
std::string、std::vector 内部调用 new 分配缓冲区，若被你的池接管，但池不支持变长分配 → 崩溃
- 异常处理机制依赖全局
operator new 抛出 std::bad_alloc，自定义实现若没严格遵循规范，会导致 catch(...) 失效
- 链接时可能被其他静态库的同名符号覆盖（尤其 Windows 下
/FORCE:MULTIPLE）
如果真要全局拦截，务必用 __gnu_cxx::__pool_alloc 这类已验证的策略，而非手写裸指针链表。
别忽略对齐与 placement new 的细节
内存池返回的地址若未按 alignof(T) 对齐，new (ptr) T 触发未定义行为（尤其 AVX/SIMD 类型）。C++17 起推荐用 std::aligned_alloc 初始化池底内存；C++11 可用 std::malloc + 手动偏移调整。
释放流程必须严格匹配：
- 用
new (ptr) T 构造 → 必须先 ptr->~T()，再将 ptr 还给池
- 绝不能写
delete ptr —— 此时调用的是全局或类内 operator delete，但该指针并非由对应 operator new 分配
- 若对象含虚函数表，而池内存未初始化为零，首次虚调用可能跳转到随机地址
最易被忽略的一点：内存池本身（如 std::vector 或 std::stack）的内存也来自堆 —— 它不该把自己也塞进自己管理的池里，否则初始化阶段就死锁。
