Java内存泄漏是指程序中已不再使用的对象因无法被垃圾回收器（GC）回收，导致内存占用持续增长，最终可能引发OutOfMemoryError，排查内存泄漏需要结合工具、日志和代码分析，以下是具体方法和步骤。
理解内存泄漏的常见特征
内存泄漏的典型表现包括：应用运行一段时间后内存占用持续上升，即使负载未增加；Full GC（老年代垃圾回收）频率逐渐增高，但回收后内存并未完全释放；最终抛出OutOfMemoryError，尤其是“Java heap space”错误，需先通过监控确认这些特征，避免误判为正常内存波动。
使用JDK工具初步定位
JDK提供了多种命令行工具,可快速定位内存异常进程和初步分析问题。
查看进程内存状态
使用jps命令列出所有Java进程及其ID，通过jstat -gc <pid> <interval>监控GC情况，每秒打印一次GC统计信息：
jstat -gc 12345 1000
重点关注老年代（Old Gen）和元空间（Metaspace）的已用空间（OU、MU）是否持续增长，以及Full GC（FGC）次数和耗时（FGCT）是否异常，若内存持续上升且FGC频繁，可能存在泄漏。
生成堆转储文件
堆转储（Heap Dump）是内存泄漏分析的核心，记录了某时刻所有对象的状态，使用jmap生成堆转储文件：
jmap -dump:format=b,file=heapdump.hprof <pid>
JDK 9及以上版本推荐使用jcmd：
jcmd <pid> GC.heap_dump heapdump.hprof
生成后,通过工具（如MAT、VisualVM）分析文件，查看内存中对象的数量、大小及引用关系。
通过可视化工具深入分析
Eclipse Memory Analyzer（MAT）
MAT是专业的堆分析工具,打开堆转储文件后，可生成“ Leak Suspects Report”（泄漏嫌疑报告），直接定位可疑对象，重点关注：
- Dominator Tree（支配树）：查看大对象及其支配关系，定位占用内存最多的对象；
- Path to GC Roots（GC根路径）：分析对象为何无法被回收，检查是否存在不合理的引用（如静态集合、未关闭的资源等）。
VisualVM
VisualVM是JDK自带的可视化工具,支持实时监控和堆转储分析，连接进程后，在“Monitor”标签页查看内存曲线，切换到“Heap Dump”标签页加载堆文件，可查看对象实例、类加载器信息，并通过“OQL”查询特定对象（如查询所有未关闭的数据库连接）。
结合线程栈分析内存泄漏
部分内存泄漏由线程问题导致,例如线程池未关闭、线程中持有对象引用等，使用jstack生成线程栈文件：
jstack <pid> > thread.txt
结合堆转储中的线程信息,检查是否存在：
- 线程池任务未执行完毕,导致任务对象无法回收；
- 线程被阻塞,持有锁或对象引用；
- 线程本地存储（ThreadLocal）未清理，导致ThreadLocalMap积累对象。
常见内存泄漏场景及排查
-
静态集合类泄漏：静态Map、List等集合未清理，导致对象无法被回收。
static Map<String, Object> cache = new HashMap<>(); public void addObject(String key, Object value) { cache.put(key, value); // 未remove，对象一直存在 }排查时通过MAT的GC根路径,确认对象是否被静态集合引用。
-
资源未关闭：数据库连接、IO流、Socket等未调用close()，导致资源无法释放，可通过MAT查看“Finalizer Queue”队列，或结合代码检查资源关闭逻辑。
-
监听器未移除：事件监听器、回调接口未移除，导致对象被隐式引用。
button.addActionListener(e -> { ... }); // 未remove，持有button引用排查时检查对象是否被监听器列表引用。
预防内存泄漏的最佳实践
- 代码规范：避免静态变量持有大对象；使用try-with-resources确保资源自动关闭；ThreadLocal使用后调用remove()。
- 工具辅助：通过SonarQube等静态代码分析工具检测潜在泄漏风险；单元测试中加入内存泄漏检测（如使用JMockit验证对象是否被回收）。
- 监控告警：线上应用使用Arthas、Prometheus监控JVM内存，设置内存使用率阈值告警，及时发现异常。
通过以上步骤,可系统性地定位和解决Java内存泄漏问题，核心思路是“监控-定位-分析-验证”，结合工具和代码逻辑，逐步缩小排查范围，最终找到泄漏根源并修复。
