直接new/delete不适合高频小对象分配，因其触发系统堆管理器导致锁竞争、内存碎片和缓存不友好；内存池通过预分配+空闲链表绕过malloc/free，配合placement new与显式析构实现高效管理。
为什么直接 new/delete 不适合高频小对象分配
频繁调用 new 和 delete 会触发系统堆管理器介入，导致锁竞争、内存碎片和缓存不友好。尤其在游戏帧循环、网络包解析等场景中，每帧创建几十上百个固定大小的 Packet 或 Event 对象时，性能损耗明显——不是语法错，是底层机制决定的。
内存池本质是「预分配一大块内存 + 自己管理空闲链表」，绕过 malloc/free 的路径。它不解决所有内存问题，但对已知大小、生命周期短、数量多的对象最有效。
手写一个固定大小内存池（含构造/析构支持）
关键点不在“分配”，而在“对象正确构造/析构”。c++ 的 placement new 和显式调用析构函数必须配对，否则 RAII 失效。
- 用
std::vector<char></char>或malloc()预分配原始内存，按固定块大小切分 - 维护一个
void*单向空闲链表（每个空闲块头部存下一个空闲块地址） -
alloc()：取链表头，更新链表指针，再用::new(p) T(args...)构造对象 -
deallocate(void* p)：先显式调用static_cast<t>(p)->~T()</t>，再把地址插回空闲链表头 - 注意：若
T有非平凡析构函数（std::is_trivially_destructible_v<t></t>为 false），必须调用；否则可跳过析构步骤提升性能
示例片段：
立即学习“C++免费学习笔记（深入）”；
template<typename T> class FixedPool { std::vector<char> memory_; void* free_list_ = nullptr; size_t block_size_ = sizeof(T); size_t capacity_; <p>public: explicit FixedPool(size<em>t n) : capacity</em>(n), memory_(n <em> block<em>size</em>) { // 构建空闲链表：每个块前 8 字节存 next 指针（64 位） for (size_t i = 0; i < n - 1; ++i) { auto</em> ptr = memory_.data() + i <em> block<em>size</em>; </em>static<em>cast<void**>(ptr) = memory</em>.data() + (i + 1) <em> block<em>size</em>; } </em>static<em>cast<void**>(memory</em>.data() + (n - 1) * block<em>size</em>) = nullptr; free<em>list</em> = memory_.data(); }</p><pre class='brush:php;toolbar:false;'>T* alloc() { if (!free_list_) return nullptr; auto* p = free_list_; free_list_ = *static_cast<void**>(p); return new(p) T(); // placement new } void deallocate(T* p) { if (!p) return; p->~T(); // 显式析构 *static_cast<void**>(p) = free_list_; free_list_ = p; }};
std::pmr::memory_resource 与自定义 pool_resource 实战差异
标准库的 std::pmr::pool_resource 是现成方案，但它默认按多个桶（bucket）管理不同尺寸块，且不保证线程安全——多线程下需外层加锁或使用 std::pmr::synchronized_pool_resource。
真实项目中容易踩坑的是：你传给 std::pmr::vector 的 memory_resource* 必须在整个 vector 生命周期内有效；若 pool 对象析构早于 vector，后续 push_back 就会访问野指针。
-
std::pmr::pool_resource适合快速验证，但调试困难（内部结构不透明） - 手写池可控制对齐（如强制 16 字节对齐适配 SIMD）、可嵌入对象头做调试标记（如 magic number / 分配栈回溯）
- 若需支持多种尺寸，别硬写多级链表——先用
std::unordered_map<size_t pool></size_t>管理不同 size 的子池，够用再优化
释放时机与生命周期管理最容易被忽略
内存池本身不跟踪对象存活状态，只管“借”和“还”。这意味着：你不能指望池自动回收未 deallocate() 的对象，也不会报错——只会表现为内存泄漏或后续分配返回脏内存（未初始化/残留旧对象数据）。
常见错误：
- 异常路径遗漏
deallocate()→ 必须用 RAII 包装，例如PoolPtr<t></t>在析构时归还 - 跨线程传递对象后，在错误线程调用
deallocate()→ 内存池通常非线程安全，需确保归还线程与分配线程一致，或改用无锁队列+线程本地池 - 对象析构函数抛异常 → 在
deallocate()中调用析构时捕获，否则栈展开中析构抛异常会 terminate
真正难的从来不是分配逻辑，而是让“借”和“还”的边界清晰、可审计。生产环境建议在池中加入计数器和分配栈记录（仅 debug 模式），否则排查野指针或 double-free 会极其痛苦。