pmap -x <pid> 可查看进程内存分布详情，包括地址范围、RSS、大小、权限及映射来源；不加参数仅显示基本信息，无法获取内存用量，必须用 -x 才显示 KB 单位的 size/RSS/dirty。
怎么用 pmap 看单个进程的内存分布
pmap 不是看“谁吃内存最多”的工具，它是查“某个进程内部哪块内存占了多少、是什么类型”的。直接跑 pmap -x <pid> 才能看到详细页表信息：地址范围、RSS（实际物理内存）、大小、权限标记，还有映射来源（比如 [heap]、[stack]、/lib64/ld-linux.so.2）。
常见错误是只跑 pmap <pid>（不加参数），结果只输出地址+权限+映射文件，根本看不到字节数，等于白看。
- 必须加
-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/<pid>/smaps 里按 Size: 和 RSS: 分组聚合（可用 awk 快速统计），或者用 smem 工具算 PSS（Proportional Set Size），它自动分摊共享内存，比 pmap 的原始 RSS 更接近真实占用。
-
cat /proc/<pid>/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 <pid>比翻pmap输出更早发现异常分配热点
真正需要 pmap 的时刻很少：比如确认某段地址是否真的映射了可执行页（检查安全加固是否生效），或者验证 mmap(MAP_HUGETLB) 是否成功分配了大页——其它时候，它只是个辅助验证手段，不是诊断起点。
