linux内存泄漏排查需聚焦进程内特定内存区持续增长，优先用smaps查private_dirty、rss等字段定位泄漏源，辅以pmap快速筛查异常映射段，再通过多轮采样对比趋势确认。
Linux内存泄漏排查，关键在定位进程内哪部分内存持续增长。smaps和pmap是两个轻量、无需额外工具、系统自带的诊断利器——前者提供按页类型（如RSS、PSS、私有脏页、mmap区域等）的详细内存分布，后者快速查看进程虚拟地址空间布局和各段大小。重点不是看总内存，而是对比多次采样中特定区域（如Anonymous、Heap、[anon:heap]、[stack]或某段mmap）是否单向增长。
smaps：精准识别泄漏源头
smaps位于/proc/[pid]/smaps，每行代表一个内存映射区，后面紧跟几十行统计字段。排查泄漏时重点关注：
- Size：该VMA的虚拟地址空间大小（可能包含未分配物理页）
- RSS：实际占用的物理内存页数（含共享页），反映真实内存压力
- PSS：比例共享大小（RSS ÷ 共享该页的进程数），更适合评估单个进程“净”内存开销
- Private_Dirty：该区域独占且被修改过的物理页数——red">泄漏最典型指标，尤其在堆或匿名映射区持续上升
- MMUPageSize 和 MMUPageSize：区分大页/普通页使用情况，有助于判断是否因大页未释放导致误判
建议用脚本定期采集关键字段，例如只提取所有[anon:heap]或[heap]段的Private_Dirty值，绘图观察趋势。若某anon段Private_Dirty从10MB涨到200MB且不回落，基本可锁定为堆内存泄漏。
pmap：快速定位异常内存段
pmap -x [pid] 输出按地址排序的映射列表，含Kbytes、RSS、Dirty三列。相比smaps更简洁，适合初筛：
- 关注Address列中起始地址接近0x7f...的高地址段——通常是动态分配的堆或mmap区域
- 留意Kbytes极大但RSS很小的段：可能是mmap(MAP_POPULATE)预分配但未真正使用，也可能是泄漏后未访问的脏页（需结合smaps确认）
- 重复执行pmap -x并diff输出，找Kbytes或RSS持续增长的行；若某段每次+4MB且标记为[anon]，大概率是brk/sbrk或mmap未free
注意：pmap默认不显示共享库符号，加-q可抑制头尾信息，便于脚本解析；加-XX可显示更多细节（如页保护标志），但非必需。
组合实战：三步缩小范围
单独看smaps或pmap都容易漏判。推荐流程：
- 用ps aux --sort=-%mem | head -5找出内存Top进程，记下PID
- 运行pmap -x [pid] | grep -E "(anon|heap|stack)" | sort -k3nr，找RSS/Dirty最大的匿名段
- 进入/proc/[pid]/smaps，定位对应地址段（如7f8b2c000000-7f8b2c400000），检查其Private_Dirty、MMUPageSize、MMUPageSize及前后是否有大量Mlocked: 0（排除锁页干扰）
若发现某anon段Private_Dirty随时间线性上涨，而代码中对应malloc/new后无free/delete，或mmap后缺munmap，即可确认泄漏点。此时配合gdb attach或coredump分析调用栈，进一步定位源码位置。
注意事项与常见陷阱
避免把正常内存行为误判为泄漏：
- 缓存膨胀：如slab cache、page cache、dentry/inode缓存会随负载增长，但属内核自动管理，一般不需干预
- 延迟释放：glibc malloc在多线程下可能暂存fastbins或tcache，pmap看到的RSS未必立刻下降，需等待几秒或触发malloc_trim
- 共享内存误读：多个进程映射同一shm或tmpfs文件时，smaps中Shared_*字段高，但Private_*稳定——不是泄漏
- JVM/Python等运行时：它们有自己的GC机制，应优先用jstat、pstack或gc日志分析，而非直接盯smaps的anon段
不复杂但容易忽略：每次采样前先触发echo 1 > /proc/sys/vm/drop_caches（仅测试环境），排除page cache干扰；生产环境则依赖Private_Dirty和长期趋势判断。
