Linux下应通过解析/proc/self/smaps中匿名映射区的Rss值来准确统计实际堆内存使用量，因其涵盖brk和mmap分配的全部物理内存，而malloc_stats()、mallinfo()等glibc接口因忽略mmap分配及多arena结构常严重低估。
Linux下用/proc/self/smaps解析实际堆内存使用量
直接读/proc/self/smaps比依赖malloc_stats()更可靠，后者只反映glibc内部统计，常严重低估（尤其启用mmap分配大块内存时）。该文件每行是Key: Value kB格式，关键字段包括：Rss:（实际物理内存）、Size:（虚拟地址空间大小）、MMUPageSize:（页大小）和MMUPageSize:（是否大页）。注意Heap:段不单独存在——堆内存分散在多个anon映射区中，需过滤Size: > 0且无文件名的条目，并累加其Rss值。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用
std::ifstream逐行读取/proc/self/smaps，跳过空行和注释行 - 匹配正则
^([A-Za-z]+):[[:space:]]+([0-9]+)[[:space:]]+kB$提取键值对 - 当遇到以
0000000000000000-开头的地址行时，重置当前映射区标记；若后续行含Anonymous:或为空文件名，则视为堆/匿名内存候选 - 累加所有匹配区的
Rss，而非仅Heap字段（该字段早已被内核弃用）
用mallinfo()和malloc_info()获取glibc分配器内部状态
mallinfo()返回struct mallinfo，但字段语义模糊（如uordblks是“已分配字节数”，但不含mmap分配部分）；malloc_info(0, fd)输出XML格式的完整堆状态，包含arena、fastbin、unsorted bin等分级数据。两者都受MALLOC_MMAP_THRESHOLD_环境变量影响——小对象走brk，大对象走mmap，导致统计割裂。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 调用
malloc_info(0, fd)前先dup2(fd, STDOUT_FILENO)或用open_memstream()捕获输出，避免文件I/O阻塞 - 解析XML时重点关注
<heap>下的nr_threads（arena数量）、<bin>标签的size和count属性 -
mallinfo()的hblkhd字段表示通过mmap分配的字节数，需与/proc/self/smaps中的AnonHugePages交叉验证 - 多线程程序必须在所有线程调用
malloc后才调用malloc_info()，否则部分arena可能未初始化
分级统计：区分brk/mmap、arena、bin层级的实际内存归属
glibc 2.26+默认启用per-thread arena，每个arena维护独立fastbins/unsorted bins，但共享main_arena的top chunk。单纯看mallinfo()会漏掉非main arena的分配，而malloc_info()的XML中每个<heap>对应一个arena，其<bin>子节点按size分组列出空闲块数量。真正的“分级”不是按业务逻辑，而是按分配器内部结构：brk区（连续小对象）、mmap区（大对象/线程栈）、各arena的bins（空闲链表）。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用
grep -E "^(heap|bin|size|count)"快速提取malloc_info()关键字段，避免全量XML解析开销 - 对比
/proc/self/smaps中AnonPages（总匿名页）与malloc_info()中所有heap的total_size之和，差值即为未被malloc管理的匿名内存（如mmap(MAP_ANONYMOUS)直调） - 检测
mmapped_count字段突增可定位大对象泄漏，而fastbin中count长期>0说明存在碎片化
跨平台兼容性与性能陷阱
Windows无/proc，需用GetProcessMemoryInfo()获取PROCESS_MEMORY_COUNTERS_EX中的PrivateUsage，但它无法区分堆/栈/其他私有内存；macOS的task_info()同样粒度粗糙。所有方案都有采样开销：malloc_info()会短暂锁住所有arena，高并发场景下可能引发延迟毛刺；频繁读/proc/self/smaps触发内核遍历VMA链表，单次耗时可达毫秒级。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 生产环境避免每秒轮询，改用信号触发（如
sigusr1）或按需dump - Linux调试时优先用
cat /proc/$(pidof yourapp)/smaps_rollup代替逐行解析，它已聚合RssAnon、SizeAnon等关键指标 - 若需实时监控，用
perf record -e 'syscalls:sys_enter_mmap,syscalls:sys_enter_brk'跟踪分配源头，而非事后统计 - 第三方库（如tcmalloc/jemalloc）完全绕过glibc接口，此时
malloc_info()返回空，必须切换为其专用API（如tc_malloc_stats()）
真正难的是把/proc/self/smaps的物理内存、malloc_info()的逻辑结构、线程arena分布这三层数据对齐——稍不留神就会把mmap内存算进brk统计，或把多个arena的重复计数当作泄漏。没有银弹，得根据具体分配模式选组合策略。
