定位Linux内存泄漏需结合smem、pmap和/proc/pid/maps：smem按USS筛查可疑进程，pmap定位增长内存段（如[heap]/[anon]），/proc/pid/maps深挖映射属性与来源，三者联动可闭环分析泄漏根因。
定位 Linux 进程内存泄漏，关键不是看“用了多少内存”，而是看“内存增长是否合理、映射区域是否异常累积”。smem、pmap 和 /proc/pid/maps 各有侧重：smem 适合横向对比多进程的内存分布；pmap 提供单进程各段（堆、栈、库、mmap 区）的大小快照；/proc/pid/maps 则是底层视图，能识别匿名映射、堆扩展、mmap 类型（如 [anon]、[heap]、[stack]、[vdso]）及权限细节。三者结合，才能判断增长是否来自堆分配未释放、反复 mmap 未 munmap，还是共享内存或大页误用。
用 smem 快速筛查可疑进程
smem 按 USS（Unique Set Size）排序最有效——USS 是进程独占的物理内存，排除共享库等干扰，内存泄漏通常首先体现为 USS 持续上涨。
- 运行 smem -s uss -r | head -20 查看 USS 最高的前 20 个进程
- 对疑似进程（如 pid=1234），加 -P "keyword" 过滤名称：smem -P "myapp" -c "pid uss pss rss cmd"
- 配合时间采样：每 30 秒记录一次 USS，观察是否单调上升（例如用 watch -n 30 'smem -P myapp -c "pid uss"' ）
用 pmap 定位增长在哪个内存段
pmap 展示进程虚拟地址空间各区域的大小和类型，可快速区分是堆（[heap]）、动态库、还是大量匿名 mmap（常见于泄漏）。
- 执行 pmap -x 1234（-x 输出 KB 单位的 RSS、Dirty、Mapped）
- 重点关注三类行：[heap]（堆区，malloc/free 不当易涨）、[anon]（匿名映射，如 mmap(MAP_ANONYMOUS)，泄漏高发区）、total 行中的 mapped（总映射量）与 writeable/private（可写私有页，近似 USS）
- 若发现数百 MB 的 [anon] 区块持续增多，且无对应业务逻辑（如缓存预分配），高度可疑
用 /proc/pid/maps 深挖映射来源与属性
/proc/pid/maps 是权威源头，能识别 mmap 标志（如 MAP_HUGETLB、MAP_SHARED）、是否可执行、是否脏页，还能结合 /proc/pid/smaps 分析 RSS/Size/PSS 细节。
- 查看映射布局：cat /proc/1234/maps | grep -E "^(7|5|6)[a-f0-9]+.*\[.*\]" | tail -10（过滤高位地址的 anon/heap 区）
- 识别可疑模式：[anon:myapp]（带名匿名映射，可能是程序主动 mmap）、[anon]（无名，常为 malloc 或 jemalloc 内部管理）、连续多段小 [anon]（可能频繁 malloc 小块未释放）
- 进一步分析某段：取地址（如 7f8b2c000000-7f8b2c100000），查 grep -A 5 "7f8b2c000000" /proc/1234/smaps，看 Rss:、MMUPageSize:、MMUPageFlags:，确认是否驻留内存且未被回收
联动分析：从现象到根因的典型路径
单一工具只能看到切片，组合使用才能闭环。例如：smem 发现某进程 USS 2 小时涨了 1.2GB → pmap 显示 [anon] 增加 1.1GB → maps 中找到 37 段 32MB 的 [anon:buffer_pool]，起始地址递增 → 结合代码确认是自定义缓冲池未做容量限制或释放逻辑缺失。
- 先用 smem 锁定“谁在涨”
- 再用 pmap 确认“涨在哪一段”（heap / anon / shared）
- 最后用 maps + smaps 判断“为什么涨不掉”（权限不可写？mmap 未 munmap？THP 导致反碎片失败？）
- 必要时用 gdb -p 1234 -ex "info proc mappings" -ex quit 辅助验证运行时映射状态
