linux内存泄漏本质是用户进程未释放内存，需通过available趋势、res增长、pmap匿名映射及valgrind定位真泄漏而非业务膨胀。
Linux系统本身不会“泄漏内存”，真正泄漏的是用户进程（尤其是C/C++程序）——它申请了内存却不释放，导致RSS持续上涨、available不断下降，最终触发OOM Killer。排查的关键不是找“系统漏洞”，而是定位哪个进程在异常增长、增长的是哪类内存、是否真没释放。
看整机内存趋势：别只信free -h的瞬间快照
很多人一看到free里used高就慌，其实真正要看的是available列是否持续下跌，以及swap的so（swap out）值是否非零且增长。用free -h -s 5每5秒采样一次，观察1–2分钟；更稳妥的做法是结合sar -r 5查历史曲线，确认下降是线性还是阶梯式。如果available从6G掉到2G且不再回升，而buff/cache没同步涨，基本可判定有进程在吃死内存。
查具体进程：用top和ps盯住RSS和VSZ变化
top默认按CPU排序，按M键可按内存（%MEM）降序；重点关注RES（常驻内存）是否缓慢但稳定上升。若某个Java或C++进程的RES从800M升到1.8G且空闲时也不回落，嫌疑最大。进一步用ps aux --sort=-%mem | head -10确认前10名；再用cat /proc/<pid>/status | grep -E "VmRSS|VmSize|MMUPageSize"</pid>看更细粒度的虚拟/物理内存分布。注意：VIRT大不等于泄漏，RES持续涨才危险。
挖根因：用pmap -x <pid></pid>看内存段分布
对可疑进程执行pmap -x <pid></pid>，重点看最后一行mapped和anon两列：如果anon（匿名映射，即堆、mmap分配的私有内存）远高于启动时，且mapped（文件映射）没明显变化，大概率是堆上泄漏。再配合cat /proc/<pid>/maps | grep -E "heap|anon" | wc -l</pid>统计匿名映射区域数量——从几十个涨到上千个，基本坐实频繁malloc未free。此时别急着上Valgrind，先确认是不是业务逻辑问题（比如缓存不淘汰、连接池堆积），这类“逻辑泄漏”pmap能看见现象，但valgrind只会报still reachable，容易误判。
验证泄漏点：valgrind --leak-check=full必须带--show-leak-kinds=all
在开发或测试环境复现问题后，用valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all --log-file=valgrind.log ./your_binary运行。关键点有三个：--show-leak-kinds=all必须显式指定，否则possible lost和still reachable会被过滤；日志里重点看definitely lost（指针丢了）和possibly lost（指针可能被覆盖）；如果输出全是still reachable，别直接放弃——检查代码里是否有全局容器不断push_back却没清理，或者mmap映射后忘了munmap。Valgrind对堆外内存（如DirectBuffer、mmap）无能为力，这类得靠pstack + /proc/<pid>/maps</pid>手动比对。
真正难的不是命令怎么敲，而是区分“真泄漏”和“业务膨胀”：前者valgrind能直接定位代码行，后者得结合业务逻辑看pmap里匿名段增长节奏和lsof -p <pid></pid>查句柄是否同步增加。很多线上泄漏拖一周才暴露，就是因为只看了free，没盯住RES的小时级趋势。
