排查Linux内存泄漏需建立“现象→定位→验证”闭环：先用free -h盯available列确认持续下降，再用top和pmap -x查进程RSS及[heap]/[anon]增长，最后用valgrind或perf定位代码级泄漏点。
排查 Linux 系统内存泄漏，关键不是找“一个命令”，而是建立“现象→定位→验证”的闭环流程。内存泄漏本质是进程持续申请内存却不释放，导致 RSS（常驻集）缓慢但稳定上升，最终触发 OOM 或服务退化。下面分三步说清楚怎么做。
看整机趋势：确认是不是真泄漏，而不是缓存或误判
先别急着杀进程。执行 free -h，重点盯住 available 列——它代表系统当前能立即分配给新进程的内存，比 free 列靠谱得多。如果 available 持续多日单向下降（比如从 6G → 4G → 2G），且 buff/cache 没同步上涨，就高度可疑。
再用 watch -n 5 'free -h' 每 5 秒刷新一次，观察变化节奏；或者用 sar -r 5（需 sysstat 包）记录历史曲线。同时检查 swap：si/so 值是否持续非零？一旦出现频繁换入换出，说明物理内存已吃紧，泄漏正在产生实际影响。
查具体进程：锁定谁在悄悄吃内存
运行 top，按 M 键按内存使用排序，关注 RES（常驻内存）列。挑出 RSS 明显增长的进程（比如两天内从 800M 涨到 1.8G），记下 PID。
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
进一步确认该进程的内存行为：
- ps -o pid,rss,vsz,comm -p [PID] —— 看 RSS 和 VSZ 是否同步涨，排除只是虚拟地址扩张
- pmap -x [PID] | tail -5 —— 查看堆段（[heap]）和匿名映射区（anon）大小，这两块涨得快，基本就是 malloc/new 泄漏的证据
- cat /proc/[PID]/status | grep -E "VmRSS|VmSize|MMUPageSize" —— 验证内核视角下的实际占用
挖根因代码：C/C++ 程序用工具实锤泄漏点
对怀疑进程，分场景选择工具：
- 生产环境粗筛：用 perf record -e 'mem-alloc:*' -p [PID] -g -- sleep 30，再 perf script 看高频分配栈，快速识别热点路径
- 开发/测试环境定案：用 valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all --log-file=valgrind.log ./your_app。输出里 definitely lost 是硬泄漏，still reachable 要结合业务判断是否该释放
- 堆外或 mmap 泄漏：检查 /proc/[PID]/maps 中大量未命名的 anon 映射段，或用 smem -P your_app -c "pid name pss uss" 看 USS（独占物理内存），USS 持续涨而 PSS 不同比例涨，往往指向 mmap 或 DirectBuffer 未释放
不复杂但容易忽略：泄漏不是瞬间发生的，一定要对比时间维度上的变化；很多所谓“泄漏”其实是缓存堆积或业务逻辑缺陷（比如日志队列不消费），先排除这些再深入代码层。
