对象池应使用malloc/free配合placement new和显式析构：malloc分配原始内存，placement new构造对象，归还时先显式调用析构函数再free释放，避免new/delete带来的自动构造/析构开销及未定义行为。
对象池该用 new/delete 还是 malloc/free
直接用 new 和 delete 会触发构造/析构，而对象池的核心诉求是复用——你希望从池里拿出来的对象状态可控、初始化开销最小。所以标准做法是：用 malloc 分配原始内存，用 placement new 手动调用构造函数；归还时显式调用析构函数，再用 free 释放内存。
常见错误是直接在 malloc 内存上调用 delete，这会触发未定义行为（delete 要求指针来自 new）。另一个坑是忘了在回收前调用析构函数，导致资源泄漏（比如对象内持有文件句柄或动态数组）。
- 分配阶段：
void* raw = malloc(sizeof(T)); T* obj = new(raw) T(); - 回收阶段：
obj->~T(); free(obj); - 若类型
T有非平凡析构函数（即不是 trivially destructible），必须显式调用~T()
如何避免多线程下 get()/put() 的竞争
对象池一旦被多个线程并发访问，get 和 put 就成了临界区。最简单的是加全局互斥锁，但高并发下会成为瓶颈。更实用的做法是：每个线程维护一个本地缓存栈（thread-local stack），只在本地栈空或满时才与共享池同步。
注意 thread_local 变量的生命周期：它在线程退出时自动销毁，但其中存放的对象若没被正确析构（比如只清空指针没调用 ~T()），就会泄漏。另外，不要把 thread_local std::stack<t></t> 直接塞裸指针——得确保这些指针指向的内存本身是池管理的，且析构逻辑一致。
立即学习“C++免费学习笔记（深入）”；
- 推荐结构：
thread_local std::vector<t> local_cache;</t>，配合大小阈值（如 16）控制与共享池的交换频率 - 共享池用
std::stack<t std::vector>></t>+std::mutex，避免用std::shared_ptr包裹池中对象——增加原子操作开销 - 切忌在
put()中做耗时操作（如日志、验证），否则拖慢整个池的归还路径
对象池要不要支持可变大小或多种类型
单类型、固定大小的对象池最容易写对、性能最好。一旦引入“泛型池”或“通用内存池”，就得面对对齐、碎片、类型擦除等复杂问题。生产环境里，90% 的优化场景其实只需要为 1–3 个高频类（如 Packet、Event、BufferNode）各自建池。
如果你真需要统一接口，别用 void* + reinterpret_cast，而是用模板特化 + 静态分发。例如：ObjectPool<connection></connection> 和 ObjectPool<request></request> 是完全独立的类型，编译期隔离，无运行时开销。
- 避免写
template<typename t> class GenericPool</typename>并试图用std::any或std::function管理不同类型的析构逻辑 - 如果池中对象大小差异大（比如从 32B 到 4KB），宁可拆成多个池，也不要搞 slab allocator —— 除非你已确认分配模式高度规律且内存碎片是主要瓶颈
- 构造参数传递是个易忽略点：
get()通常不带参数，若需传参（如get(int id)），应在池外预构造好参数包，或用工厂函数注入，而非让池承担参数转发逻辑
怎么判断你的对象池真的提升了性能
别只看吞吐量数字。先用 perf record -e cache-misses,task-clock ./your_app 对比启用池前后的 L3 缓存未命中率和系统调用次数。如果 brk / mmap 系统调用大幅减少，且对象生命周期集中在池的 get/put 路径上，那才是有效优化。
典型误判是：开了池但对象实际存活时间远超平均使用周期（比如池中对象平均被复用 1.2 次），或者池大小设得太小导致频繁向系统申请新内存块（表现为 malloc 调用没降多少）。这时候池反而增加了间接跳转和分支预测失败。
- 监控关键指标：池命中率（
get从本地/共享池返回的比例）、平均驻留时间（对象从put到下次get的间隔） - 用
valgrind --tool=massif查内存峰值，确认池没造成内存常驻上涨 - 如果对象有虚函数表或继承关系，确保 placement new 构造时 vptr 初始化正确——某些编译器在异常路径下可能不保证
