/proc/self/maps 是唯一可靠来源，因内核动态生成全进程vma列表，覆盖主线程栈、线程栈、堆、共享库等，不区分线程，真实反映地址空间布局。
直接读 /proc/self/maps，不是看 top 或 ps，也不是调 mallinfo —— 多线程不改变进程级虚拟内存布局结构，但会影响 [stack] 区域数量和分布。
为什么 /proc/self/maps 是唯一可靠来源
Linux 内核每次读取 /proc/self/maps 都动态生成当前进程全部 VMA（Virtual Memory Area）列表，覆盖主线程栈、所有 pthread 创建的线程栈、堆、共享库、vdso、vvar、匿名映射等。它不区分线程，只反映整个进程地址空间的最终映射状态——这正是“布局”的本质。你不会在 top 里看到哪块地址属于哪个线程，mallinfo 只管 malloc 管理的主堆，而线程栈、mmap 分配的大对象、TLS 段全都不计入其中。
常见错误现象：用 std::ifstream 打开后直接 operator>> 逐词读取，结果因字段间空格/制表符不一致、路径含空格（如 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.30）导致解析错位；或误信 VMSize 字段能代表布局结构——它只是个总和数字，没地址、没权限、没语义。
- 必须用
fgets()或std::getline()逐行读，再用sscanf(line, "%lx-%lx %4s %lx %x:%x %lu", &start, &end, perm, &offset, &dev_major, &dev_minor, &inode)提取前六字段 - 路径从第 7 字段起，需手动跳过前导空白后取整段（不能按空格切）
- 内核新版可能在权限后插入额外字段（如 mm_struct flags），
%4s比依赖字段索引更稳
如何识别多线程引入的关键区域
主线程栈标记为 [stack]，其余每个 pthread 创建的线程栈在 /proc/self/maps 中表现为独立的 [stack:XXXX] 行（XXXX 是线程 tid），权限为 rw-p，无文件路径，大小通常与 ulimit -s 一致（默认 8MB），但实际驻留页（RSS）远小于此。
容易被忽略的点：[stack:XXXX] 不是堆，也不归 malloc 管理；它由内核在 clone() 时通过 MAP_GROWSDOWN 映射，起始地址低、向高地址扩展，和主线程栈方向一致；若线程使用了大缓冲区或递归过深，可能触发栈扩展，对应 VMA 的 end 地址会变大。
- 不要靠路径名过滤线程栈——有些环境（如 musl libc）可能不带
:XXXX后缀，只写[stack] - 所有线程栈都应排除在“堆虚拟大小”统计之外；若混入，会导致高估可回收内存
- TLS（Thread Local Storage）段通常落在
[stack]或独立[anon]区域中，无固定标记，需结合地址范围与线程数估算
解析时避开 mmap 和 std::vector 的陷阱
C++ 中 new 大对象（≥128KB 默认阈值）、std::vector::reserve() 大容量、mmap(MAP_ANONYMOUS) 都不会进 [heap]，而是落在独立的 [anon] 区域，权限 rw-p，起始地址对齐到页大小（getpagesize()）。这类区域数量多、碎片化严重，是多线程程序虚拟内存增长的主要来源之一。
常见误判：看到 [heap] 很小就认为堆没压力——其实真正的大块内存都在一堆 [anon] 里；或把 [vdso]/[vvar] 当作可释放内存——它们是内核注入的只读辅助页，不计入 RSS，但占虚拟地址空间，且不可卸载。
-
[vdso]和[vvar]总是成对出现，大小固定（通常各 4KB），用于加速gettimeofday等系统调用 - 区分
[anon]类型：主线程brk扩展出的叫[heap]；pthread 内部 TLS 分配、std::thread栈初始化、new大数组，基本都走mmap→[anon] - 不要用
std::ifstream+mmap加速读/proc/self/maps——procfs 伪文件不支持mmap，会返回EINVAL
容器环境下特别注意 /proc 权限和挂载限制
在 Docker 或 Kubernetes 中，/proc/self/maps 仍可用，但可能被只读挂载、裁剪（如 procfs 以 hidepid=2 挂载），导致读取失败或仅返回部分行。此时 fopen("/proc/self/maps", "r") 可能成功但内容为空或缺失关键区域（如 [stack]）。
实操建议优先 fallback 到 /proc/[pid]/maps（用 getpid() 拼路径），并检查 errno：若为 EACCES，说明被 hidepid 限制；若为 ENOENT，可能是容器未挂载完整 procfs。
- 别依赖
system("cat /proc/self/maps")——shell 启动慢、不可控，且容器中可能禁用sh - 某些安全加固策略（如 gVisor、Kata Containers）会拦截 procfs 访问，返回空或模拟数据，需结合
getrlimit(RLIMIT_AS)和/proc/self/status的VmSize交叉验证 - 若解析出的
[stack]区域远少于预期线程数，大概率是hidepid或容器运行时过滤所致，不是线程没创建成功
真正难的不是读取，而是区分哪些 [anon] 是线程私有、哪些是共享内存、哪些是临时缓存——这些信息不在 /proc/self/maps 里，得靠程序自己标记或结合 mincore() 查驻留状态。别指望一次解析就画出完整拓扑图，先确保每块区域的地址、权限、语义都认得准。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
