java应用内存泄漏的典型表现为内存持续上涨、gc频繁且回收差、响应变慢甚至oom；需通过jstat监控、gc日志分析、heap dump抓取及mat工具定位静态集合、资源未关闭、监听器未解绑、threadlocal未清理等高频泄漏点，并验证修复效果。
Java 应用出现性能瓶颈，如果伴随内存持续上涨、GC 频繁且回收效果差、响应变慢甚至 OutOfMemoryError，大概率是内存泄漏在拖累系统。分析这类问题不能只看“慢”，而要锁定“哪些对象不该留却一直留着”。关键路径是：监控异常 → 抓取快照 → 定位泄漏源 → 验证修复。
观察内存行为，确认泄漏迹象
先判断是不是真泄漏，而不是单纯高负载：
- 用
jstat -gc <pid> 2s</pid>持续观察：老年代（Old Gen）使用率是否单向攀升，Full GC 后仍不下降；Eden 区频繁 Minor GC 但老年代不释放 - 用
VisualVM或JConsole查看堆内存曲线：是否呈阶梯式上升，每次 GC 后内存基线越来越高 - 启用 GC 日志：
-Xlog:gc*,gc+heap=debug:file=gc.log:time，检查日志中是否有 “Allocation Failure” 频发、晋升失败（Promotion Failed）或长时间 Full GC
生成并分析堆转储（Heap Dump）
发现异常后立即抓取现场快照，这是定位根源的核心依据：
- 用
jmap -dump:live,format=b,file=heap.hprof <pid></pid>导出实时存活对象快照（加live可过滤已标记为待回收的对象） - 用 Eclipse MAT 打开 hprof 文件，重点关注：
- Leak Suspects Report：MAT 自动生成的疑似泄漏报告，通常直指问题类和引用链
- Dominator Tree：按 retained heap（该对象被回收后能释放的总内存）排序，找出吃内存最多的对象及其支配关系
- Path to GC Roots：对可疑大对象右键 → “Show Objects by Class” → 选一个实例 → “Path to GC Roots” → 勾选 “with all references”，查看它为什么无法被回收（比如被静态 Map 强引用、被 ThreadLocal 持有、被监听器链间接持有）
聚焦高频泄漏点，快速代码验证
不必大海捞针，优先排查这几类典型模式：
-
静态集合无清理：搜索
static Map/static List，检查是否只增不删；确认缓存是否有过期策略或容量限制 -
资源未关闭：查找
InputStream、Connection、Statement等使用处，是否用了try-with-resources；没用的，检查finally块里是否调用了close() -
内部类/监听器未解绑：GUI 或事件驱动代码中，注册监听器（如
addXXXListener）后，是否在对象销毁时调用对应removeXXXListener -
ThreadLocal 未清理：搜索
ThreadLocal.set()，确认配套使用了ThreadLocal.remove()，尤其在线程池复用场景下
验证修复效果，闭环确认
改完代码后别直接上线，要实测验证：
- 本地或测试环境重复触发原业务流程，用 VisualVM 对比修复前后堆内存增长趋势
- 再次生成 Heap Dump，用 MAT 检查原泄漏对象是否不再出现在 Dominator Tree 顶部，且 Path to GC Roots 已断开
- 运行一段时间后，观察 GC 日志中老年代占用是否稳定，Full GC 是否显著减少
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
