mallinfo仅反映glibc malloc管理的堆内存（不含mmap分配），已deprecated；更可靠的是读取/proc/self/status中的VmRSS（物理内存占用，KB）或VmData（数据段大小），二者由内核维护、不受分配器影响。
Linux 下用 mallinfo 获取堆内存分配概况
mallinfo 是 glibc 提供的轻量级接口，能快速拿到当前进程通过 malloc/free 管理的堆内存统计，比如已分配字节数、空闲字节数、分配块数等。但它只反映 malloc 系统（即 ptmalloc）的内部视图，不包含 mmap 分配的大块内存或 C++ new 可能绕过的路径。
使用时注意：mallinfo 在较新 glibc（2.33+）中已被标记为 deprecated，且返回结构体字段语义模糊（如 uordblks 是“已使用的字节”，但不含 malloc header 开销；fordblks 是“空闲字节”，但可能包含不可合并碎片）。示例：
#include <malloc.h> #include <iostream> <p>struct mallinfo mi = mallinfo(); std::cout << "used: " << mi.uordblks << " bytes\n"; std::cout << "free: " << mi.fordblks << " bytes\n";
- 必须链接
-lc（默认已连），无需额外编译选项 - 线程安全：每个线程有独立 malloc state，
mallinfo返回调用线程所在 arena 的主分配区统计，多线程下不能代表全局 - 对
new分配不一定全覆盖——若 libstdc++ 启用了 pool allocator（如__gnu_cxx::__pool_alloc），这部分内存不会计入mallinfo
更可靠的方法：解析 /proc/self/status 中的 VmRSS 和 VmData
当需要真实物理内存占用或粗略评估整体动态内存压力时，读取 /proc/self/status 更稳定。它由内核维护，不受用户态分配器实现影响。
关键字段：
立即学习“C++免费学习笔记（深入）”；
-
VmRSS：当前驻留物理内存（KB），含堆、栈、共享库数据段、mmap 匿名页等，最接近“程序实际占了多少 RAM” -
VmData：数据段大小（KB），大致对应堆 + brk 区域，但不含 mmap 分配的堆外内存（如malloc大于 MMAP_THRESHOLD 时走的mmap） -
VmStk和VmLib可辅助排除干扰
实操建议：
#include <fstream>
#include <string>
#include <regex>
<p>long get_vm_rss_kb() {
std::ifstream f("/proc/self/status");
std::string line;
while (std::getline(f, line)) {
if (std::regex_match(line, std::regex(R"(VmRSS:\s+(\d+)\s+kb)"))) {
return std::stol(line.substr(line.find_first_of("0123456789")));
}
}
return -1;
}
- 不要依赖
VmSize（虚拟地址空间总大小），它包含未分配页、保留区、只读代码段，和动态内存无关 - 该方式在容器中依然有效，只要 procfs 挂载且可读（默认都满足）
- 性能开销极小，单次读取约几十微秒，适合采样监控，但别在 tight loop 里高频调用
想追踪每次 new/delete？重载全局 operator new/delete
如果目标是精确统计 C++ 对象生命周期内的堆分配行为（比如查泄漏、分析热点分配），必须拦截 new 和 delete。glibc 的 mallinfo 或 /proc 都做不到这点。
最小可行重载示例：
#include <new>
#include <atomic>
<p>static std::atomic_size_t total_allocated{0};</p><p>void<em> operator new(std::size_t n) {
void</em> p = malloc(n);
if (p) total_allocated += n;
return p;
}</p><p>void operator delete(void* p) noexcept {
if (p) {
// 需要额外记录 size（如用 malloc_usable_size 或自建 header）
free(p);
}
}
- 必须同时重载所有变体：
operator new(size_t, std::nothrow_t)、operator new[](size_t)等，否则部分分配会绕过统计 - 无法获取
malloc_usable_size对new返回指针的准确值（因new可能加 cookie），稳妥做法是在分配前用malloc+ 自定义 header 封装 - 重载后会影响所有静态链接的库，若项目依赖第三方库且其内部有特殊内存管理（如某些游戏引擎），可能引发冲突
为什么不用 valgrind --tool=massif？
Massif 是精准堆分析工具，但它不是“程序内获取统计”的方案——它是外部运行时注入，会拖慢程序 10–50 倍，且输出是文件而非实时变量。适合离线诊断，不适合嵌入到服务逻辑中做周期性上报或阈值告警。
典型误用场景：
- 在生产环境 LD_PRELOAD massif.so —— 不支持，massif 必须用
valgrind启动 - 期望从代码里调用某个 massif API 获取当前快照 —— 不存在这样的接口
- 用 massif 替代
mallinfo解决多线程统计问题 —— massif 本身是单线程采集，多线程下峰值可能漏掉竞争窗口
真正需要运行时细粒度统计时，重载 operator 是唯一可控路径；若只要宏观水位，/proc/self/status 最省心。两者混合用也常见：用 VmRSS 做告警阈值，用重载日志做归因分析。
