Ubuntu上定位与修复Java内存泄漏的实用步骤
一 快速确认与应急
- 识别异常日志特征：重点关注 OutOfMemoryError，如 Java heap space（堆内存不足）、Metaspace（元空间）、Direct buffer memory（直接内存）、或 unable to create new native thread（线程创建失败）。这些关键词能快速指向泄漏或资源瓶颈的方向。
- 先做应急止血：临时提高堆上限以恢复服务，例如 -Xms1g -Xmx4g；同时开启故障现场留存，便于后续根因分析。
- 立即开启留存参数（建议在启动脚本中固化）：
- -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/your-app/heapdump.hprof（OOM时自动落盘堆转储）
- 按需设置 -XX:MaxDirectMemorySize=…（直接内存上限）
- 注意：堆调大只能缓解表象，无法修复泄漏根因，应尽快进入定位阶段。
二 现场取证与定位
- 进程与GC状态：
- 查看进程：jps -l
- 观察GC与内存分区：jstat -gc 1000 10（关注 OU/EU 是否持续增长、Full GC 后是否回收）
- 堆与线程快照：
- 堆概要：jmap -heap
- 触发堆转储：jmap -dump:live,format=b,file=heapdump.hprof （线上谨慎，会触发 STW）
- 线程栈：jstack > threads.txt（排查线程泄漏、阻塞等）
- 图形化分析：
- jvisualvm 或 Eclipse MAT 打开 heapdump.hprof，优先看 Histogram/Dominator Tree 与 Leak Suspects 报告，定位占用最多且本应被回收的对象及其引用链。
三 常见根因与修复要点
- 静态集合/缓存无限增长：使用 WeakHashMap/SoftReference、设置 TTL/最大容量 与 定期清理（如 ScheduledExecutorService）。
- 监听器/回调未注销：在对象销毁或模块卸载时 显式 removeListener。
- 线程与线程池滥用：避免 new Thread()，统一使用 线程池 并控制 核心/最大线程数 与 队列容量。
- 资源未关闭：数据库连接、文件流、网络连接等使用 try-with-resources 或 finally 可靠关闭。
- 大对象/集合驻留：分批处理、流式处理，避免一次性加载全量数据到内存。
- 第三方库缓存/会话：核查其 缓存策略 与 过期机制，必要时替换为可配置的策略或加监控告警。
四 参数与运行环境优化
- 堆与元空间：
- 堆：-Xms 与 -Xmx 设为相同值以减少动态扩缩带来的抖动（如 -Xms2g -Xmx2g）。
- 元空间（JDK 8+）：默认无上限，建议设置 -XX:MaxMetaspaceSize=… 防止无界增长。
- 直接内存：如 Netty/NIO 使用较多，设置 -XX:MaxDirectMemorySize=… 并结合业务压测确定上限。
- GC策略：根据延迟/吞吐目标选择 G1/ZGC/Shenandoah（JDK 11+ 建议优先 ZGC/Shenandoah 以降低停顿）。
- 容器场景：在 Kubernetes/Docker 中设置容器内存上限，并让 -Xmx 小于容器上限，为 元空间/直接内存/本地内存 预留空间，避免被 OOMKilled。
五 监控与预防
- 持续观测：
- 系统层：top/htop/free/vmstat 观察 RSS/内存压力。
- JVM层：jstat 持续看 GC 次数/时间 与 老年代使用率。
- 可视化：jvisualvm/JConsole 或商业工具 JProfiler/YourKit 做长期内存与分配热点分析。
- 告警与复盘：对 频繁 Full GC、GC 时间飙升、Heap/Meta/Direct 持续增长 设置告警；每次 OOM 后基于 heapdump.hprof 复盘并补充单元/集成测试，形成回归防护。