malloc_stats()可快速查看堆总量与碎片，但输出不可解析；mallinfo2()提供结构化指标更可靠；分级统计需LD_PRELOAD劫持或使用tcmalloc/jemalloc内置分析。
Linux下用malloc_stats()快速看堆分配总量与碎片情况
malloc_stats()是glibc提供的轻量级接口，能立刻打印当前进程堆的粗粒度统计（如已分配字节、空闲字节、系统向内核申请的总内存），但它不记录历史走势，也不分级——只输出到stderr，且仅在使用glibc malloc时有效。调用前无需初始化，但输出不可编程解析：
malloc_stats(); // 输出类似：Arena 0: system bytes: 135168, in use bytes: 98304
常见误用是把它当监控接口反复调用并试图解析输出——实际每行格式不稳定（尤其多arena时），且无时间戳。真要采样，得重定向stderr再做文本解析，代价高、易出错。
用mallinfo()或mallinfo2()提取结构化堆指标
mallinfo()返回struct mallinfo，含uordblks（已分配字节）、fordblks（空闲字节）等字段，但字段单位模糊（如smblks含义依赖实现），且已被标记为过时；mallinfo2()（glibc 2.33+）用size_t统一单位，字段更明确（如ordblks是空闲块数）。关键限制：两者都只反映当前快照，无历史数据。
实操建议：
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 若需每秒采集，直接调用
mallinfo2()比解析malloc_stats()输出更可靠 - 注意
mallinfo2()在musl libc上不可用，跨平台需预编译检查 - 字段
hblkhd（mmap分配字节数）和usmblks（mmap释放阈值）常被忽略，但对判断是否频繁触发mmap很关键
用LD_PRELOAD劫持malloc/free实现分级统计
真正要按“对象类型”或“分配大小区间”分级统计，必须拦截分配路径。最可行的是写一个so，用LD_PRELOAD注入，重写malloc、free、realloc。核心难点不在拦截，而在线程安全与性能损耗：
- 每个分配需记录大小、调用栈（用
backtrace()）、时间戳——但backtrace()在信号上下文可能死锁，建议只在非关键路径启用 - 分级统计建议按2的幂次分桶（如0–16B、16–32B…），避免为每个size单独计数
- 务必用
__atomic操作更新计数器，否则多线程下数值会跳变 - 别在hook里做I/O（如写文件），否则分配慢100倍以上；数据先存环形缓冲区，另起线程异步刷出
用libtcmalloc或jemalloc内置profiling替代手写
手动hook容易漏掉new/delete、std::allocator等C++层调用，而libtcmalloc（Google）和jemalloc提供开箱即用的堆分析能力。例如：
export HEAPPROFILE=/tmp/myapp; ./myapp # tcmalloc生成.prof文件
然后用pprof可视化：pprof --text ./myapp /tmp/myapp.0001.heap。它们天然支持：
- 按调用栈聚合分配量（解决“谁分配了最多内存”问题）
- 增量快照对比（
--base参数看内存增长点） - 按size class自动分级（如“large object” vs “small bin”）
但要注意：libtcmalloc默认关闭profiling以保性能，需显式启用；jemalloc的prof_active:true需通过mallctl动态开启，且采样率（prof_sample）设太高会导致分配延迟飙升——通常100KB采样间隔较平衡。
真正难的是把“走势”落到时间轴上：这些工具本身不持续打点，得靠外部定时器触发快照（如每30秒调一次mallctl("prof.dump", ...)），而两次快照间的分配泄漏可能被掩盖。除非你愿意接受每毫秒一次采样——那程序基本跑不动。
