Windows下用\_heapwalk可统计当前已分配总量，需调试模式静态链接CRT并启用调试堆跟踪；Linux/macOS用malloc\_info或mallinfo仅得粗略堆状态；跨平台精确统计应重载operator new/delete；“已释放总量”无实际意义。
Windows下用_heapwalk遍历堆块统计分配总量
Windows CRT 提供了 _heapwalk 函数，能遍历当前进程的本地堆（非所有堆，仅 CRT 默认堆），但它不直接返回“已释放量”，只能靠遍历识别已分配/空闲块。注意：_heapwalk 仅在调试模式（_DEBUG 定义）且链接静态 CRT（/MTd）时才可靠工作；动态链接（/MDd）下行为未定义，多数情况下直接失败或崩溃。
实操要点：
- 必须用
_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF)启用调试堆跟踪 - 调用前需确保没有其他线程在分配/释放内存，否则遍历可能中断或读到脏数据
-
_HEAPINFO结构中_used字段为非零表示已分配块，_size是块大小（不含头部开销），累计即可得当前已分配总量 - 空闲块（
_used == 0）的_size是可复用空间，但不等于“历史上释放过的总量”——它只是当前空闲池大小，无法回溯历史释放行为
Linux/macOS下用mallinfo或malloc_info获取粗略堆状态
mallinfo 在 glibc 中已标记为废弃（deprecated），返回字段含义模糊（如 uordblks 是“已分配字节数”，但不包含 malloc 内部元数据、对齐填充、以及 mmap 分配的大块），且无法区分“当前占用”和“历史峰值”。更推荐用 malloc_info(0, fd) 输出 XML，再解析 <total> 和 <free> 字段。
关键限制：
立即学习“C++免费学习笔记（深入）”；
-
malloc_info只反映 libc 主分配器（ptmalloc）的状态，不包括通过mmap(MAP_ANONYMOUS)直接申请的大内存页 - 输出中的
total≈ 当前已分配（含元数据），free是当前空闲链表总和，二者差值接近“当前实际占用用户数据量”，但不是精确的净分配量 - macOS 的
malloc_zone_statistics可替代，但只对默认 zone 有效；若程序用了自定义 zone，需显式传入句柄
跨平台统一方案：重载operator new和delete做全局计数
如果目标是精确统计“你的代码触发的 new/delete 次数与字节数”，最可靠的方式是全局重载 operator new、operator delete 及其数组变体，并用原子变量累加。注意：这不能捕获 malloc/free、STL 容器内部调用、第三方库的分配行为。
典型实现需处理：
- 所有重载签名：
void* operator new(size_t)、void* operator new[](size_t)、带noexcept和std::align_val_t的 C++17 版本 - 释放端必须严格匹配分配签名，否则
delete可能调用错误的operator delete，导致计数错乱或崩溃 - 多线程下用
std::atomic<size_t>计数，避免锁开销；但要注意：new本身可能被 STL 内部频繁调用，高频场景下原子操作仍是瓶颈 - 必须排除
placement new（不分配内存）——它不调用全局operator new，无需计数
为什么没有真正的“已释放总量”指标？
操作系统和 malloc 实现都不保留“累计释放字节数”这个值。释放动作只是把内存块标记为空闲、合并邻块、可能还归还给 OS（madvise(MADV_DONTNEED) 或 munmap），但不会递增某个全局计数器。所谓“已释放量”，本质上是个无意义的概念：同一块内存可能被反复分配-释放多次，累加会严重失真；而空闲链表大小只是瞬时快照，不是历史积分。
真正有用的是两个指标：
- 当前 RSS / VSS（用
/proc/self/statm或getrusage）——反映进程实际占物理/虚拟内存 - 分配峰值（
_CrtMemCheckpoint+_CrtMemDifference在 Windows 下可做到，Linux 需自己记录）——用于定位内存泄漏
试图用“分配总量减空闲量”算出“已释放量”，既没语义支撑，也因元数据、碎片、mmap 分离等干扰而不可靠。
