/proc/[pid]/status 是获取进程内存分级统计最准、最轻量的方式，因其提供内核按用途硬性分类的 vmdata、vmstk、vmexe、vmlib、vmrss 等字段，可精准区分堆、栈、代码段、共享库等，且不依赖外部工具、无采样与聚合。
直接读 /proc/[pid]/status 是获取进程内存分级统计最准、最轻量的方式——它不依赖外部工具，不采样，不聚合，就是内核当前快照。
为什么 top 和 ps 不能满足内存分级分析需求
这些工具只提供粗粒度汇总值：RES（常驻内存）把所有映射进物理内存的页全加在一起，但你无法知道其中多少是 libc 共享库、多少是 malloc 分配的堆、多少是 mmap 的匿名区；VIRT 更只是虚拟地址空间总大小，大量区域（如未 touch 的 mmap 区）根本没分配物理页。
而 /proc/[pid]/status 的 VmData、VmStk、VmExe、VmLib、VmRSS 等字段，是内核按内存用途硬性分类的，可精准区分代码段、堆、栈、共享库、页表开销等。
-
VmRSS≠ 进程独占内存 —— 它包含共享库页，多个进程共用同一份libc时，这部分被重复计入每个进程的VmRSS -
VmSize是虚拟地址空间总大小，VmRSS才反映真实物理占用 -
VmSwap不代表“正在交换”，而是当前被换出到 swap 的页数；值为 0 并不意味进程没被 swap 过，只是当前全在 RAM 中
如何快速提取关键内存字段
用 grep 配合 Vm 前缀是最常用方式，例如：
cat /proc/1234/status | grep Vm
输出类似：
VmPeak: 124568 kB VmSize: 124568 kB VmRSS: 8924 kB VmData: 4216 kB VmStk: 88 kB VmExe: 320 kB VmLib: 2044 kB VmPTE: 56 kB VmSwap: 0 kB
重点关注这几个字段：
-
VmData：堆（heap）占用，含brk/sbrk和大部分malloc分配 -
VmStk：用户栈大小（固定约 8 MB 以内，通常很小） -
VmExe：可执行文件代码段（.text） -
VmLib：共享库（如libc.so）映射部分 -
VmRSS：当前实际驻留物理内存总量（含上述所有 + 共享页）
/proc/[pid]/status 里容易被忽略的非内存字段
除了 Vm*，这个文件还包含大量诊断线索，比如：
-
State：进程当前状态（R运行、S休眠、Z僵死），比ps的STAT更底层 -
Threads：当前线程数，排查线程泄漏时比ps -T -p [pid]更快 -
voluntary_ctxt_switches和nonvoluntary_ctxt_switches：主动/被动上下文切换次数，高nonvoluntary值往往暗示 CPU 竞争或锁争用 -
CapEff:行显示有效 capabilities，排查权限问题时比getpcaps [pid]更直接
实际排查中几个典型误判点
很多同学看到 VmRSS 就当“进程实际用了多少内存”，结果误判 OOM 根因。真正要关注的是：
- 多个子进程共用相同共享库时，
VmLib在每个进程中都计入VmRSS，但物理页只一份 —— 所以VmRSS总和会远超系统真实内存占用 -
VmData持续上涨大概率是堆泄漏，但需排除mmap(MAP_ANONYMOUS)分配（它不走brk，不体现在VmData，而算进VmRSS） -
VmPTE（页表页大小）异常高，可能说明进程有大量小碎片mmap区域，触发了内核页表膨胀，影响 TLB 效率
别只盯着一个数字看，VmData、VmRSS、VmLib 三者趋势对比，才能定位是堆泄漏、共享库加载异常，还是 mmap 使用失控。
