结论：靠new/delete或malloc/free长期运行必然碎片化，不换分配策略无解；真正有效的是预分配+复用机制。std::pmr::synchronized_pool_resource通过分桶固定尺寸分配、页内切分与整页归还避免外部碎片；monotonic_buffer_resource适用于短时批处理，零碎片但不可单对象释放；手写池须严控对齐、空闲链表安全及线程原子性，且无法挽救内部自行堆分配的数据结构导致的碎片。
直接说结论：靠 new/delete 或 malloc/free 长期运行必然碎片化，不换分配策略就无解。真正有效的办法是绕过默认堆分配器，用预分配+复用机制控制内存生命周期。
为什么 std::pmr::synchronized_pool_resource 能缓解外部碎片
它不是“修复”碎片，而是从源头避免碎片产生路径：
- 内部按固定尺寸分桶（如 16B/32B/64B…），同尺寸请求永远从同一子池取，释放后直接插回空闲链表，不参与跨块合并
- 每个子池维护自己的大块内存页（通常 4KB 或更大），小块分配只在页内切分，不会把空洞散落在整个堆上
- 当某子池空闲块足够多时，会批量归还整页给操作系统——这步能回收连续空间，而标准
free很少这么做 - 注意：它对 短生命周期、大小集中 的对象最有效，比如网络包解析中的
PacketHeader、SessionContext
monotonic_buffer_resource 适合什么场景
它根本不处理“释放单个对象”，而是整段内存一次性退掉，因此零外部碎片、零内部碎片（除末尾未用部分）：
- 典型用法是函数局部作用域内做临时数据聚合，比如解析一帧图像的所有元数据：
std::pmr::vector<metadata> meta{&buf_res}</metadata> - 必须确保所有对象生命周期严格嵌套在资源作用域内，否则出作用域后指针立刻悬垂
- 不能混用：一旦用
monotonic_buffer_resource分配了对象，就不能用delete或其他分配器去释放它 - 性能极高，但内存只增不减——适合“分配一次、用完即弃”的批处理，不适合长期内存复用
手写固定大小对象池要注意的三个坑
自己实现比用 std::pmr 更灵活，但也更容易翻车：
立即学习“C++免费学习笔记（深入）”；
-
对齐没处理好：比如对象需要 8 字节对齐，但池内偏移计算用了
sizeof(T)直接累加，结果第二块内存地址不是 8 的倍数，触发硬件异常 - 空闲链表指针覆盖原对象内存：释放时把下一个空闲块地址写进对象首字节，但如果对象构造函数已往那里写了数据，就会破坏链表结构
-
线程安全假象：加了 mutex 就以为安全？如果两个线程同时调用
allocate()，一个刚取走块、另一个紧接着取走同一块，说明你没把“取块 + 标记为已用”做成原子操作
最常被忽略的一点：内存池再好，也救不了设计层面的碎片——比如把 std::string 和 std::vector<int></int> 这种内部自己 new 的类型塞进池里，它们的底层缓冲区依然走系统堆。真正要控碎片，得从数据结构选型开始，优先用栈数组、std::array、预分配容量的 vector，而不是等碎片出来再补救。
