最可靠方法是通过/proc/self/status读取VmRSS和VmSize，结合/proc/self/maps解析[heap]区域估算堆虚拟大小，而精确的分配/释放总量必须通过LD_PRELOAD拦截malloc/free实现。
Linux下用/proc/self/status读取堆内存快照
Linux进程的堆使用情况无法通过标准C++ API直接获取，但内核在/proc/self/status中暴露了近似指标。关键字段是VmRSS（当前驻留物理内存）、VmSize（虚拟地址空间总大小），而真正反映堆分配总量的是HeapAlloc类指标——可惜它不在默认status里。实际能稳定读到的是VmData（已初始化数据段+堆估算值）和VmStk（栈），但VmData会混入全局变量、BSS段，不能等同于malloc分配量。
更可靠的做法是解析/proc/self/maps中标记为[heap]的内存区域：
- 它只有一行，起始与结束地址可算出当前堆虚拟大小
- 但不区分已分配/已释放/未使用，仅反映brk系统调用的当前上限
- 驻留量仍得靠VmRSS减去其他段估算，误差通常在几MB内
示例代码片段：
#include <fstream>
#include <string>
#include <regex>
<p>size_t get_heap_size_kb() {
std::ifstream f("/proc/self/maps");
std::string line;
while (std::getline(f, line)) {
if (line.find("[heap]") != std::string::npos) {
std::regex r(R"(^([0-9A-Fa-f]+)-([0-9A-Fa-f]+)\s+)");
std::smatch m;
if (std::regex_search(line, m, r)) {
auto start = std::stoul(m[1].str(), nullptr, 16);
auto end = std::stoul(m[2].str(), nullptr, 16);
return (end - start) / 1024;
}
}
}
return 0;
}Windows下用GetProcessHeap + HeapWalk遍历堆块
Windows提供较底层的堆枚举能力，但必须注意：默认进程堆（GetProcessHeap()）只覆盖HeapAlloc/LocalAlloc系调用，不包含malloc（CRT私有堆）或new（可能映射到不同堆）。若程序混用CRT和WinAPI内存函数，统计会严重缺失。
使用HeapWalk需满足：
- 调用前关闭堆锁（HeapLock(h)），否则可能死锁或返回失败
- 每次调用返回一个PROCESS_HEAP_ENTRY结构，dwFlags含PROCESS_HEAP_ENTRY_BUSY才表示已分配块
- cbData字段即该块字节数，累加即得当前分配总量
- 已释放块（空闲）不计入，也无法得知历史释放次数
关键限制：
- HeapWalk不可重入，多线程环境下必须暂停所有其他线程或确保无堆操作
- CRT的malloc默认使用私有堆，需改用_malloc_dbg并开启调试堆才能被HeapWalk捕获
跨平台方案：LD_PRELOAD拦截或MSVC调试堆钩子
想精确统计malloc/free调用次数与字节数，唯一可靠方式是劫持内存分配函数。Linux可用LD_PRELOAD注入自定义malloc实现；Windows可用MSVC的_CrtSetAllocHook。
立即学习“C++免费学习笔记（深入）”；
Linux示例要点：
- 实现malloc、free、realloc、calloc四个符号，内部调用__libc_malloc等真实函数
- 全局原子计数器记录总分配量、当前驻留量、释放次数
- 注意free(nullptr)必须允许，且realloc可能等价于malloc+memcpy+free，需拆解计数
- 动态库需编译为-fPIC -shared，运行时LD_PRELOAD=./libhook.so ./your_program
Windows调试堆钩子：
- 仅在Debug模式下有效，Release版无_CrtSetAllocHook
- 钩子函数接收int nAllocType（_HOOK_ALLOC/_HOOK_FREE等）
- 可记录每次调用地址、大小、调用栈（用_CrtDbgReport或CaptureStackBackTrace）
- 但无法捕获非CRT分配（如DirectX、OpenSSL内部malloc）
为什么mallinfo和malloc_stats不推荐用于生产环境
mallinfo在glibc 2.33+已被标记为废弃，返回的arena、ordblks等字段语义模糊，且不支持多arena场景（现代glibc默认启用多个heap arena以提升并发性能）。调用后返回的usmblks（可分配空间）常远大于实际malloc用量，uordblks（已分配）又不含mmap分配的大块内存。
malloc_stats()输出到stderr，无法结构化解析，且输出格式随glibc版本变动：
- 某些版本显示“max mmap regions”，某些则省略
- “system bytes”包含所有sbrk+mmap申请量，但“in use bytes”只统计当前busy块，不等于驻留物理内存
- 多线程下统计值可能瞬间不一致，无原子保证
真正需要精确指标时，别依赖这些接口。要么走/proc或WinAPI底层枚举，要么自己挂钩——后者虽重，但数据可信。
记住：堆总量 ≠ 驻留量 ≠ 逻辑使用量。三者差值取决于操作系统页回收策略、内存碎片、分配器延迟合并等，同一时刻三个数可能差数倍。测的时候关掉其他干扰进程，多次采样取趋势，别信单次读数。
