高频小对象分配导致堆碎片是因为通用分配器无法专为固定小尺寸优化，boost::pool通过预分配大块内存和链表管理绕过系统堆，但需按大小和生命周期分池并正确重载operator new。
为什么 new 和 malloc 在高频小对象场景下会快速产生碎片
频繁分配/释放几十到几百字节的对象（比如 std::shared_ptr 控制块、事件结构体、节点类），会让堆管理器反复切分和合并空闲内存块。glibc 的 malloc 在小块分配时倾向使用 fastbins 和 unsorted bin，但一旦分配模式不规则（大小不一、生命周期交错），空闲块就难以合并，形成大量无法复用的“孔洞”。这不是你代码写错了，是通用分配器的设计取舍——它得兼顾大块、长生命周期、随机大小，没法专为你的 64 字节节点优化。
- 典型现象：
valgrind --tool=massif显示heap_tree中大量0x... (in /usr/lib/x86_64-linux-gnu/libc.so.6)占据高位，但实际存活对象远少于总分配量 - 关键诱因：对象大小在 16–128 字节之间 + 生命周期差异大（有的几毫秒，有的几秒）
- 不是内存泄漏，
leak-check=full报告干净，但 RSS 持续上涨后不回落
用 boost::pool 快速验证是否真能缓解碎片
别自己从头写池子——先用 boost::pool 看效果。它按固定块大小预分配大块内存，内部用单向链表管理空闲块，分配就是指针偏移+链表摘除，释放就是插回链表，完全绕过系统堆管理器。
- 必须显式指定块大小：
boost::pool<std::size_t> pool(sizeof(MyNode));，不能传变量，得是编译期常量 - 分配/释放必须成对：
pool.malloc()得配pool.free(ptr)，混用delete或free()会直接崩溃 - 线程不安全：多线程必须加锁，或每个线程独占一个
pool实例（推荐后者） - 示例片段：
struct MyNode { int id; char data[48]; }; boost::pool<std::size_t> node_pool(sizeof(MyNode)); MyNode* n = static_cast<MyNode*>(node_pool.malloc()); // ... use n ... node_pool.free(n); // 不是 delete n！
自定义内存池要注意 operator new 的重载边界
想让 new MyNode 自动走池子？可以，但必须重载类作用域的 operator new，全局重载风险极高（影响所有第三方库）。
- 只在类内声明：
struct MyNode { void* operator new(size_t sz) { assert(sz == sizeof(MyNode)); // 防止派生类误用 return node_pool.malloc(); } void operator delete(void* ptr) noexcept { node_pool.free(ptr); } private: static boost::pool<std::size_t> node_pool; }; - 禁止在重载里调用
malloc或new——这会导致递归调用 - 如果类有虚函数或继承体系，
sizeof可能变化，此时必须用alignof对齐并预留 vptr 空间，否则运行时踩内存 - 析构函数仍会被正常调用，但
operator delete必须保证不抛异常（noexcept）
真正决定碎片改善程度的是对象生命周期分布
池子本身不解决“长期存活对象卡在中间导致大片内存无法回收”的问题。如果一批 MyNode 创建后持续 5 秒才释放，而其他对象每 10ms 分配释放一次，池子里的大块内存会被长期占用，新分配只能不断向后扩展，最终还是触发系统 brk 或 mmap，RSS 上涨。
- 检查手段：
perf record -e 'syscalls:sys_enter_mmap' -p $(pidof your_app)，如果频繁看到mmap调用，说明池子已满，正在 fallback 到系统分配 - 解决方案：按生命周期分池——短命对象用小池（如 4KB 块），长命对象单独池或直接用
new - 别迷信“一个池子管所有”：混合大小对象（比如同时存 32B 和 96B 结构）必须拆成两个池，否则浪费率飙升
碎片改善不是靠换工具，是靠把对象的生存时间、大小、访问模式摊开来看。池子只是把“不可控的堆行为”变成“可控的内存布局”，剩下的事还得你自己划清楚边界。
