对象池适用于生命周期短、大小固定、构造析构开销可控的场景；需预知大小、避免跨池资源、重置副作用、手动对齐与析构；std::pmr::memory_resource 适合容器内存定制，但不替代需预构造/自定义析构的对象池。
直接上结论：频繁 new/delete 的性能下降，80% 以上来自堆锁竞争、内存碎片和缓存不友好——不是你代码写得慢，是默认分配器在高并发/小对象场景下天然扛不住。解决它，不靠调优，靠绕开。
对象池（ObjectPool）适合什么场景？
当你反复创建销毁**生命周期短、大小固定、构造/析构开销可控**的对象时，ObjectPool 是最直接有效的方案。典型如网络请求上下文、游戏子弹、日志临时结构体、解析器 token 节点。
- 必须预知对象大小（
sizeof(T)），且不能动态变化 - 对象不应持有跨池生命周期的资源（比如全局单例指针、未关闭的 fd）
- 若
T的构造函数有副作用（如打开 socket、加载配置），要确保复用时状态可重置；否则容易出现“脏对象”问题 - 线程安全需显式处理：单线程可用无锁栈；多线程建议用
thread_local缓存 + 全局池兜底，避免所有线程都争抢一个free_list
placement new + 预分配内存块怎么写才不出错？
核心是两步：先申请一大块原始内存（std::vector<:byte></:byte> 或 malloc），再用 new (ptr) T() 在指定地址构造对象。最容易错的是对齐和析构。
- 原始内存必须按
alignof(T)对齐，否则placement new行为未定义；std::aligned_alloc或std::vector默认不保证，得手动处理 - 归还对象时，必须显式调用
obj->~T()，不能只把指针塞回空闲栈——否则析构函数不执行，资源泄漏 - 不要混用：从池中
allocate()出来的对象，禁止用delete；从堆上new出来的，禁止往池里deallocate() - 示例关键片段：
char* raw = static_cast<char*>(std::aligned_alloc(alignof(T), size * sizeof(T)));<br>T* obj = new (raw + idx * sizeof(T)) T(); // 构造<br>obj->~T(); // 归还前必须析构<br>std::free(raw); // 池销毁时释放整块
std::pmr::memory_resource 能替代手写池吗？
可以，但要看你用在哪。C++17 的 std::pmr::memory_resource 提供了标准化接口，std::pmr::pool_options 背后就是个内存池，但默认实现（如 libstdc++ 的 unsynchronized_pool_resource）并不适合所有场景。
立即学习“C++免费学习笔记（深入）”；
- 它对齐和分块策略是固定的，无法定制构造/析构逻辑，所以不适用于需要“预构造对象”的
ObjectPool场景 - 多线程下，某些标准库实现的池资源仍会共享元数据，存在隐式锁；实测中，自研无锁对象池比
std::pmr::unsynchronized_pool_resource快 2–3 倍（尤其在每秒百万级分配时） - 如果你只是想让
std::vector、std::string等容器走池内存，可以用std::pmr::polymorphic_allocator包装，但注意：容器内部仍可能触发额外的小内存分配（如std::string的 small string optimization 之外的扩容）
真正难的不是写出来，而是判断什么时候不该用池：比如对象大小不固定、构造成本极低（仅几个 int 赋值）、或者生命周期天然跨多个模块——这时候强行套池，反而引入状态管理复杂度和归还遗漏风险。性能优化的第一步，永远是用 perf record -e 'syscalls:sys_enter_brk,syscalls:sys_enter_mmap' -g 确认系统调用是否真成了瓶颈，而不是凭感觉开池。
