频繁new/delete导致堆碎片，因释放内存仅标记为空闲而不立即合并，形成大量不可用小空洞；虽总空闲量充足，但大块分配仍失败，引发bad_alloc或性能下降。
为什么 new/delete 频繁调用会导致堆碎片
堆内存不是按顺序“填满”就完事的。每次 new 分配一块大小不一的内存，delete 释放后，系统只标记那块区域为空闲，但不会自动合并相邻空闲块（尤其在 glibc 的 ptmalloc 实现中，合并有延迟且依赖后续分配触发）。久而久之，堆里散落着大量小而无法复用的空洞——这就是碎片。它不降低总空闲量，却让后续大块分配失败，比如你明明还有 100MB 空闲，却 new char[8192] 失败。
常见错误现象：std::bad_alloc 突然出现、程序运行越久越慢、valgrind --tool=massif 显示堆峰值稳定但“in use”波动剧烈。
- 典型场景：高频创建/销毁小对象（如网络包解析中的
Packet、游戏循环里的临时Vec3） - 关键点：碎片本质是“空闲内存不可用”，不是“内存不够”
- 注意：
operator new默认不保证返回地址对齐，某些 SIMD 或 GPU 交互场景下，未对齐 + 碎片会引发隐性崩溃
用对象池（object pool）绕过频繁 new/delete
核心思路：提前申请一大块连续内存，自己管理其中对象的构造/析构，new 和 delete 只调用一次（或极少次数），后续全是内存拷贝和 placement new。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用
std::vector<:byte></:byte>或std::aligned_storage_t预分配内存，确保对齐满足目标类型要求（如alignof(MyClass)） - 维护一个空闲索引栈（
std::stack<size_t></size_t>），分配时弹出索引，释放时压入——避免遍历链表找空位 - 构造必须用 placement new：
new (ptr) MyClass(args...)；析构必须显式调用：obj->~MyClass() - 别直接
delete[]池内存，等整个池生命周期结束再一次性释放
示例关键片段：
class ObjectPool {
std::vector<std::byte> memory;
std::stack<size_t> free_list;
public:
ObjectPool(size_t count) : memory(count * sizeof(T), 0) {
for (size_t i = count; i-- > 0; ) {
free_list.push(i);
}
}
T* allocate() {
if (free_list.empty()) return nullptr;
auto idx = free_list.top(); free_list.pop();
return new (memory.data() + idx * sizeof(T)) T(); // placement new
}
void deallocate(T* ptr) {
ptr->~T(); // 必须显式析构
free_list.push((reinterpret_cast<std::byte*>(ptr) - memory.data()) / sizeof(T));
}
};
std::pmr::polymorphic_allocator 能否解决碎片
可以，但不是银弹。它把内存分配策略从“硬编码到全局堆”解耦为可插拔的 std::pmr::memory_resource，让你能换用 std::pmr::monotonic_buffer_resource（只增不减）或自定义池资源。
使用场景与限制：
- 适合短期批量对象（如一次 HTTP 请求内所有临时结构体），用
monotonic_buffer_resource配合std::pmr::vector，请求结束一键 reset - 不能用于长期存活、生命周期交错的对象（比如一个对象 A 在池中，另一个 B 引用了 A 的指针，但池 reset 后 A 已失效）
- 注意：C++17 起支持，但 MSVC 2019 前版本
std::pmr实现有 bug；GCC 10+、Clang 12+ 较稳 - 性能影响：虚函数调用开销（
memory_resource::allocate是虚函数），高频小分配下比裸指针池略慢
哪些情况其实不该手动优化
现代 libc malloc（如 glibc 2.34+）对小对象（new/delete 开销极低，盲目上池反而增加复杂度和 cache miss。
- 优先怀疑是否真存在碎片问题：用
malloc_stats()或mallinfo()（Linux）看smblks（小块数量）是否持续增长 - 如果对象大小固定、生命周期一致，且每秒分配 std::vector 预留容量 + 移动语义通常比手写池更安全
- 多线程下注意：全局
new本身有锁，但自定义池若没加锁（如无锁栈），可能引发 ABA 问题；不如直接用thread_local池
真正难处理的是跨模块、跨 DLL 边界的对象生命周期——此时连 delete 都可能调错 heap，得靠约定分配器传递，而不是纠结碎片本身。
