必须用pmap -x PID查看进程内存映射地址空间，因pmap只接受数字PID、不解析进程名，Address列为起始虚拟地址，按升序列出所有VMA，配合Mapping列可快速定位[heap]、[anon]等关键内存段。
直接用 pmap -x PID 查地址空间，别用进程名
想看某个进程的内存映射地址空间，必须用数字 PID，pmap python3 或 pmap nginx 会报 illegal process ID。pmap 不解析进程名，只认整数。
- 查带参数的 Python 应用：
pgrep -f "myapp.py"（比ps aux | grep干净，不匹配自己） - 查 systemd 服务主进程：
systemctl show --property MainPID nginx.service | cut -d= -f2 - 多个同名进程时，用
ps -o pid,ppid,comm -C nginx找 PPID=1 的 master 进程
pmap -x 输出里 Address 列就是真实虚拟地址
pmap -x PID 按虚拟地址升序列出所有 VMA（Virtual Memory Area），每行第一列 Address 就是该段起始地址，十六进制格式，可直接用于 gdb -p PID 后的 info proc mappings 对照验证。
- 堆段通常地址连续、权限为
rw-p，Mapping 标为[heap] - 主线程栈一般在高地址端，如
7ffd12345000开头，大小常为 1–8MB - 共享库可能分多段（
r-xp代码段、rw-p数据段），地址不连续但路径相同 - Mapping 为空或标
[anon]的段，基本是mmap(MAP_ANONYMOUS)分配，无文件 backing
为什么不用 pmap 默认模式或 pmap -XX
默认 pmap PID 只显示地址、大小、权限和映射名，没有 RSS 和 Kbytes，看不出哪段真占物理内存；pmap -XX 字段冗余（比如重复出现 MMUPageSize），且部分内核不支持，反而干扰判断。
-
pmap -x固定输出 6 列：Address、Kbytes、RSS、Dirty、Mode、Mapping，刚好覆盖定位问题所需维度 -
RSS总和 ≈ 进程实际物理内存占用（单位 KB），top的RES就是它 -
Dirty高且持续增长，说明某段内存（如[heap]或[anon]）在频繁写入却未释放
看到可疑地址段后下一步做什么
pmap -x 只告诉你“这里映射了什么”，不告诉你“谁申请的”。地址本身不能直接定位泄漏点，但它能圈出重点区域供进一步分析。
- 若
[heap]的RSS持续上涨，优先用gdb -p PID+info proc mappings确认范围，再结合应用层堆分析工具（如 Python 的tracemalloc、Java 的jmap） - 若大量小块
[anon]RSS 累加异常高，大概率是 native 层分配失控（如 C 扩展、JVM DirectBuffer、Pythonarray.array底层），需用valgrind --tool=memcheck或perf record -e syscalls:sys_enter_mmap追踪分配源头 - 别依赖
ps aux的RSS列——它只给总值，无法区分堆、栈、共享库各自占多少
真正卡住人的不是命令怎么敲，而是拿到 pmap -x 输出后，盯着 Mapping 列快速扫三类区域：[heap]、[anon]、共享库的 rw-p 行——其他多数可以跳过。
