内存泄漏排查需遵循“现象→定位→验证→修复”四步闭环：盯死available值持续下降、vmstat中free单边下滑且si/so频繁跳动；用ps和pmap锁定anon增长进程；java用mat分析heap.hprof，c/c++用valgrind或gdb查[anon]异常；同时排查oom killer日志与系统干扰。

服务器内存泄漏排查不是靠猜，关键在“现象→定位→验证→修复”四步闭环。重点不是堆命令，而是理解内存为什么没被释放、谁在持续占着不还。

看准内存是否真在漏

别只盯着free -h的used列——它包含缓存，会误导判断。盯死available值：如果连续几小时持续下降，且buff/cache没同步上涨，基本可确认泄漏。再配合vmstat 2 10观察free列是否单边下滑、si/so（Swap读写）是否频繁跳动，这两项同时出现，泄漏概率极高。

宝塔Linux面板11.3.0

宝塔面板11.3.0是一款针对Linux服务器设计的可视化管理工具，通过重构核心模块实现资源占用显著降低，尤其适合低配置服务器环境。它将复杂的命令行操作转化为直观的图形界面，帮助开发者快速完成网站部署、环境配置及日常运维工作，无需专业技术背景即可高效管理服务器。

下载

快速锁定嫌疑进程

• 用ps aux --sort=-%mem | head -n 5找出内存占比最高的几个进程
• 对目标进程执行pmap -x <pid></pid>，重点关注anon（匿名映射）和mapped（文件映射）两列——若anon随时间明显增长，大概率是堆内存泄漏
• 查/proc/<pid>/status</pid>里的VmRSS（实际物理内存）和VmPeak（历史峰值），如果VmRSS不断逼近VmPeak且不回落，说明内存只进不出

分语言针对性验证

Java应用：加启动参数-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/，等OOM触发后用MAT分析heap.hprof，重点关注Leak Suspects报告和dominator tree里长期存活的大对象链；同时检查static集合、未关闭的Connection/InputStream、监听器未注销等高频泄漏点。

C/C++服务：用valgrind --leak-check=full --show-leak-kinds=all ./your_binary跑一次典型业务流，重点看definitely lost行数；线上无法停机时，可用gdb -p <pid></pid>后执行info proc mappings对比多次内存段变化，发现异常增长的[anon]区域。

别忽略系统层干扰

• 检查dmesg | grep -i "out of memory\|kill process"，确认是否已被OOM Killer干掉过进程
• 运行journalctl -u your-service --since "2 days ago" | grep -i "malloc\|oom"，关联应用日志找泄漏起点
• 临时调大vm.overcommit_memory=2并设vm.panic_on_oom=0，避免误杀关键服务，争取排查窗口