高频小对象频繁调用new/delete的主要开销在于堆管理器锁竞争、元数据维护和碎片整理，而非内存分配本身；glibc malloc多线程下仍可能触发brk/mmap系统调用，延迟不可控。
为什么 new/delete 会拖慢高频小对象分配
频繁调用 new 和 delete 分配小对象（比如几十字节的节点、事件结构体）时，实际开销主要不在内存本身，而在堆管理器的锁竞争、元数据维护和碎片整理。glibc 的 malloc 在多线程下默认用 per-thread arena，但小对象仍可能触发 brk 或 mmap 系统调用，延迟不可控。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 先用
perf record -e syscalls:sys_enter_brk,syscalls:sys_enter_mmap看是否真在频繁进内核——如果不是，瓶颈可能在别的地方，别急着上内存池 - 确认对象大小稳定且生命周期短（如链表节点、协程栈帧），否则通用内存池反而增加管理成本
- 避免为单次使用的临时对象（如函数内局部
std::string）强行套内存池，STL 自带 small-string optimization 已经够用
std::pmr::memory_resource 怎么接进现有代码
std::pmr::memory_resource 是 C++17 引入的标准接口，不是具体实现，得配一个实际后端（比如 std::pmr::pool_options 控制的 std::pmr::synchronized_pool_resource）。它不替换全局 new，而是通过容器模板参数或显式传参介入。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 对已有容器改用 PMR 版本：把
std::vector<int></int>换成std::pmr::vector<int></int>，构造时传入池实例：std::pmr::vector<int> v{&my_pool}</int> - 不要直接继承
std::pmr::memory_resource写自定义池——除非你清楚do_allocate/do_deallocate的线程安全契约；优先用标准提供的synchronized_pool_resource或unsynchronized_pool_resource - 注意：PMR 容器的迭代器、指针仍指向池内内存，但析构时不会自动归还——必须确保池的生命周期长于所有使用它的容器
手写简易固定大小内存池的关键陷阱
自己写 FixedBlockPool<t></t> 看似简单，但容易在对齐、析构、线程安全三处翻车。尤其当 T 有非平凡析构函数时，placement new 分配后必须显式调用 T::~T()，而裸 free 不会触发它。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 块大小必须是
alignof(T)的整数倍，且首地址按该对齐；用std::aligned_alloc分配大块，再用std::align切分 - 释放时不能只归还指针到空闲链表——得先调用
ptr->~T()，否则 RAII 类型（如含std::mutex成员）资源泄漏 - 空闲链表指针若存在跨线程访问（比如生产者/消费者共用一个池），必须用
std::atomic<t></t>或加锁；别信“我只读不写”的直觉，编译器重排可能让读写乱序
内存池和 std::shared_ptr 能一起用吗
能，但不能直接用 std::make_shared<t></t>，因为它内部调用全局 new。必须用定制删除器 + 原始指针构造，且确保控制块（control block）和对象都在同一池中——标准库不提供这种接口，得绕过。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 放弃
std::shared_ptr，改用std::unique_ptr<t pooldeleter></t>，自定义PoolDeleter调用池的deallocate方法 - 如果非用
shared_ptr，可用std::shared_ptr<t>{new (pool.allocate()) T{}, PoolDeleter{&pool}}</t>，但控制块仍在堆上——这不是真正意义上的池化 - 更现实的做法：把共享语义下沉到业务层，比如用原子计数+裸指针，避免控制块开销
真正难的是生命周期交叉——池销毁时，还有多少对象被外部持有？这没法靠技术自动解决，得靠设计约束：比如限定池只用于 request-scoped 对象，请求结束就整体清空。
