new[]/delete错配会破坏堆元数据：new[]写入对象数量供delete[]读取析构，delete却忽略该值致析构缺失、空闲链表错误更新，使内存块被异常切割而加剧碎片化。
为什么 new[] 和 delete[] 不匹配会加剧碎片化
不是所有内存泄漏都会立刻暴露，但 new[]/delete 错配会悄悄破坏堆管理器的元数据结构。编译器在 new[] 分配时会在内存块前写入对象数量（比如 100），delete[] 依赖这个值调用析构函数并更新空闲链表；而 delete 会忽略它，直接按单个对象处理——结果就是：部分内存被标记为“已释放”，实际对象未析构，后续分配可能复用该区域但残留状态混乱，空闲块被切割得更碎。
用 malloc_usable_size() 快速验证碎片是否真实存在
Linux 下可直接检查某块堆内存的实际可用尺寸，比看 top 的 RSS 更精准：
int* arr = new int[1024]; size_t actual = malloc_usable_size(arr); // 返回实际分配的字节数，通常 > 1024*4 std::cout
- 如果
actual明显大于请求大小（如请求 4KB 却返回 8KB），大概率是堆管理器找不到更紧凑的空闲块，只能从更大块里切 - 反复执行类似分配+释放后，
malloc_usable_size()返回值波动剧烈，是外部碎片的典型信号 - 注意：该函数仅对
malloc/new返回的指针有效，且非标准 C++，仅限 glibc 环境
用 AddressSanitizer 捕获隐式碎片诱因
AddressSanitizer 不只报越界，还能暴露“看似正常却加速碎片”的行为，比如：
- 频繁分配/释放不同尺寸的小数组（如
new int[3]、new double[7]），ASan 的malloc_large统计会显示大量small类别分配峰值 - 在循环中用
new[]创建临时缓冲区但未池化，日志里会出现成片的heap-buffer-overflow预警（即使没真越界，也说明相邻块被高频扰动） - 启动时加
-fsanitize=address -g编译，运行后检查 ASan 输出中的Allocated size与Requested size差值分布
替换为 std::vector 或内存池前，先确认是不是真问题
很多所谓“数组碎片”其实是误判——std::vector 内部仍是 new[]，只是封装了；盲目换方案可能引入新开销。优先做三件事：
- 用
pstack <pid></pid>查看当前堆栈中哪些函数在高频调用new[]，聚焦真实热点 - 检查数组生命周期：是否本该是栈数组（
int buf[256]）却被误写成堆分配 - 确认是否真的需要动态尺寸：若尺寸固定且已知，
std::array零成本，完全规避堆操作
碎片化真正的麻烦点在于它不报错、不崩溃，只让 malloc 调用越来越慢，且在低内存压力下几乎不可见——等你注意到 new 开始卡顿，系统可能已经运行数天了。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
