Linux查看进程内存占用方法

本文深入解析了 Linux 中 `pmap -x` 命令的正确用法与常见误区，强调它并非用于快速定位内存大户的工具，而是专精于剖析单个进程内部内存分布细节——如各内存段（[heap]、[stack]、共享库、匿名映射）的地址范围、实际物理驻留内存（RSS）、脏页（dirty）及映射来源；文章明确指出不加 `-x` 参数将无法获取关键内存用量数据，并揭示了 RSS 总和远超系统实际内存占用的根本原因（共享内存重复计数、写时复制、页表视角局限等），同时对比了 `ps/top` 与 `pmap` 的本质差异，指出其在容器环境、Java 进程、大内存场景下的局限性，最后推荐更高效精准的替代方案（如 `/proc/pid/smaps` 聚合分析、`smem` 计算 PSS、`perf` 动态追踪），帮助读者摆脱盲目依赖 `pmap` 的惯性，建立分层、精准、高效的内存问题诊断思维。

怎么用 pmap 看单个进程的内存分布

pmap 不是看“谁吃内存最多”的工具，它是查“某个进程内部哪块内存占了多少、是什么类型”的。直接跑 pmap -x 才能看到详细页表信息：地址范围、RSS（实际物理内存）、大小、权限标记，还有映射来源（比如 [heap]、[stack]、/lib64/ld-linux.so.2）。

常见错误是只跑 pmap （不加参数），结果只输出地址+权限+映射文件，根本看不到字节数，等于白看。

• 必须加 -x 才显示 KB 单位的 size、RSS、dirty
• 加 -XX 可以看到更细的页大小（如 2MB huge page 是否启用），但多数调试场景不需要
• 如果提示 Permission denied，不是权限不够，而是该进程开启了 ptrace 保护（比如被 gdb 附着过或设置了 PR_SET_DUMPABLE=0），普通用户无法读其内存映射

pmap 和 ps/top 的关键区别在哪

ps aux --sort=-%mem 或 top 显示的是 VIRT（虚拟内存总量）和 RES（常驻物理内存），它们快、适合排序找大户；但完全看不出这 500MB RES 是堆分配的、mmap 的、还是共享库的代码段——而这正是 pmap 的价值。

典型误用：用 pmap 替代 ps 查“哪个进程最耗内存”，效率极低，还容易漏掉多线程共享内存的重复计算（pmap 每个线程都算一遍 [stack]，但物理内存其实只一份）。

• ps 的 RES 是去重后的物理内存估算，pmap -x 的 RSS 总和通常显著大于它
• pmap 不统计 swap，也不反映 page cache 是否被回收，单纯看它容易误判“内存泄漏”
• Java 进程用 pmap 会看到大量 [anon] 区域，但无法区分是堆、Metaspace 还是 DirectByteBuffer，得结合 jstat 或 jcmd

为什么 pmap -x 输出里 RSS 加起来远超 free 显示的已用内存

因为 RSS 是按每个 VMA（虚拟内存区域）单独统计的，而多个进程 mmap 同一块共享内存（如 System V shm、tmpfs 文件、或 fork() 后的写时复制页），在各自 pmap 里都会计入 RSS，但物理内存只算一份。

另一个常见混淆点：[heap] 和 [anon] 区域的 RSS 值，并不等于 malloc 分配的字节数——glibc 的 brk 和 mmap 分配器会预分配、合并、延迟释放，pmap 看到的是内核页表里的实际驻留页，不是用户层 malloc 统计。

• 同一个 shmget 创建的共享内存段，在 3 个进程的 pmap -x 输出中会各算一次 RSS
• mmap(MAP_SHARED) 映射的文件，其 RSS 包含已加载进内存的文件页，但这些页可能同时被 page cache 复用
• 容器环境（如 Docker）中，pmap 看到的仍是宿主机视角的页表，不感知 cgroup memory limit

替代方案：什么时候不该硬用 pmap

查内存泄漏或定位大对象，pmap 很快就会卡住——它要遍历整个进程地址空间，对上百 GB 虚拟内存的 Java 或数据库进程，pmap -x 可能卡住几秒甚至分钟，且输出几千行根本没法人工扫。

这时候优先看更上层的指标：比如 /proc//smaps 里按 Size: 和 RSS: 分组聚合（可用 awk 快速统计），或者用 smem 工具算 PSS（Proportional Set Size），它自动分摊共享内存，比 pmap 的原始 RSS 更接近真实占用。

• cat /proc//smaps | awk '/^Size:|^RSS:/ {sum+=$2} END {print sum}' 可粗略算总 RSS（单位 KB）
• smem -P "java" -c "pid pss uss command" 能直接看到去重后的真实内存占比
• 动态追踪用 perf record -e 'mem-loads,mem-stores' -p 比翻 pmap 输出更早发现异常分配热点

真正需要 pmap 的时刻很少：比如确认某段地址是否真的映射了可执行页（检查安全加固是否生效），或者验证 mmap(MAP_HUGETLB) 是否成功分配了大页——其它时候，它只是个辅助验证手段，不是诊断起点。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Linux查看进程内存占用方法》文章吧，也可关注golang学习网公众号了解相关技术文章。