JVM 中的内存泄漏：常见场景（静态集合、线程池）与检测工具（MAT）使用
JVM 内存泄漏的常见场景
静态集合滥用
静态集合（如 static HashMap）的生命周期与类加载器一致，若不断向其中添加对象且未清理，会导致对象无法被回收。例如：
public class LeakyClass {private static final Map<String, Object> CACHE = new HashMap<>();public void addToCache(String key, Object value) {CACHE.put(key, value); // 长期运行后可能堆积大量无用对象}
}
线程池未正确关闭
线程池中的任务或线程持有外部对象的引用（如通过闭包捕获的上下文），若任务未完成或线程池未调用 shutdown()，相关对象无法释放。例如：
ExecutorService pool = Executors.newFixedThreadPool(5);
pool.submit(() -> {SomeResource resource = new SomeResource(); // 若任务阻塞，resource 无法回收// ...
});
内存泄漏检测工具 MAT 的使用
生成堆转储文件（Heap Dump）
通过以下方式获取堆转储：
- 命令行：
jmap -dump:format=b,file=heap.hprof <pid> - JVM 参数：
-XX:+HeapDumpOnOutOfMemoryError（OOM 时自动生成） - 工具触发：如 VisualVM 或 JConsole 的堆转储按钮。
MAT 分析步骤
- 打开堆转储文件后，检查 Histogram 视图，按对象实例数或大小排序，关注异常增长的类。
- 使用 Dominator Tree 识别内存占用最高的对象及其引用链。
- 通过 Path to GC Roots 功能查看泄漏对象的引用路径，定位未被释放的原因。
关键分析技巧
- 过滤无关对象：在查询框中使用
OQL（如select * from java.util.HashMap）。 - 对比多次堆转储：通过 Compare Baselines 功能观察对象增长趋势。
- 关注 Retained Heap 列：表示对象实际占用的内存（包括其引用的对象）。
实际案例演示
假设分析一个静态集合泄漏：
- 在 Dominator Tree 中发现
HashMap实例占用过高。 - 展开引用链后，发现其被
static修饰的变量持有。 - 结合代码确认该集合未被清空逻辑，建议增加定期清理或弱引用机制（如
WeakHashMap）。
预防建议
- 避免长生命周期对象持有短生命周期对象的引用。
- 使用弱引用（
WeakReference）或软引用（SoftReference）管理缓存。 - 对线程池任务进行超时控制，并确保资源显式释放（如
try-finally块）。