内存泄漏排查关键看RSS持续单向上升和available内存不可逆下降，需通过free、vmstat、ps、jstat/pmap等工具组合验证增长趋势并排除缓存干扰。
排查内存泄漏导致的系统内存持续增长，关键不是找“谁占得多”，而是看“谁涨得准”。真正的泄漏表现为进程 RSS 持续单向上升、available 内存缓慢但不可逆地下降，且不随负载回落或时间推移而缓解。
先确认是不是真泄漏：盯住 available 和 swap 活动
运行 free -h，重点看 available 列是否随时间推移持续减少。即使 free 或 used 数字波动大，只要 available 走低、且 swap 中的 so（swap out）开始出现非零值（用 vmstat 1 10 查），就说明系统已进入真实内存压力阶段，不是缓存堆积那么简单。
- 可用内存低于总内存的 15%～20%，风险明显上升
- vmstat 中 si/so 持续大于 0 KB/s，基本可判定在换页
- 如果 dmesg | grep -i "killed process" 或 journalctl -k | grep -i oom 有输出，说明 OOM Killer 已介入——泄漏已到临界点
定位嫌疑进程：用 RSS 而非 VSZ 或 %MEM
执行 ps -eo pid,cmd,rss --sort=-rss | head -10，重点关注 RSS（Resident Set Size） 值。RSS 表示实际驻留在物理内存中的字节数，比 VSZ（虚拟地址空间）和 %MEM（占总内存比例）更能反映真实内存占用。
- 对疑似进程，用 watch -n 5 "ps -p PID -o pid,rss,vsz,%mem,cmd" 每 5 秒刷新一次，观察 RSS 是否稳定或缓慢爬升
- 若 RSS 在无请求、空闲状态下仍每分钟增长几十 MB，高度可疑
- 注意区分缓存型服务（如 Redis、Elasticsearch）——它们 RSS 高但合理；泄漏的特征是“只增不减”
验证增长趋势：排除缓存干扰，聚焦长期变化
很多服务会随运行时间缓存数据，但健康缓存会在压力释放后回落。真正泄漏不会自我修复。
- 记录同一进程 RSS 值，间隔至少 30 分钟以上（比如上午 10 点、11 点、12 点各记一次）
- 对比期间系统负载（uptime 或 cat /proc/loadavg）是否同步升高；若负载平稳而 RSS 持续涨，倾向泄漏
- 检查 /proc/meminfo 中 Slab、SReclaimable 是否异常增大，可能指向内核模块或驱动泄漏
深入进程内部：对 Java/C/C++ 进行针对性分析
确认进程后，按语言特性进一步深挖：
- Java 进程：用 jstat -gcutil PID 5s 看老年代（O）使用率是否持续攀升、FGC 频次是否激增；再用 jmap -histo:live PID | head -20 查看存活对象中是否有异常多的自定义类实例
- C/C++ 进程：用 pmap -x PID 查看各内存段（尤其是堆段 anon-rw）是否不断扩张；配合 /proc/PID/status 中的 VmRSS 和 VmData 对比，判断是堆分配失控还是 mmap 泄漏
- 通用手段：cat /proc/PID/smaps_rollup | grep "^Rss\|^Pss\|^AnonHugePages" 可快速汇总该进程整体内存构成
