JAVA 应用频繁触发 OOM？使用 MAT 工具分析堆内存泄漏来源

大家好，今天我们来聊聊一个让很多 Java 开发者头疼的问题：OOM，也就是 OutOfMemoryError。更具体地说，我们将探讨如何利用 Memory Analyzer Tool (MAT) 来定位和解决 Java 应用中的堆内存泄漏问题。

OOM 往往意味着我们的应用正在耗尽 JVM 分配给它的堆内存，导致程序崩溃。虽然原因有很多，但内存泄漏是最常见也是最难诊断的一种。内存泄漏的本质是：对象已经不再被使用，但垃圾回收器 (GC) 仍然认为它们是活跃的，无法回收，导致这些对象持续占用内存，最终引发 OOM。

理解 OOM 的类型与原因

在深入 MAT 之前，让我们先了解一下 OOM 常见的类型和原因。

OOM 类型	原因
`java.lang.OutOfMemoryError: Java heap space`	这是最常见的 OOM 类型，表示堆内存不足。通常由内存泄漏、过大的对象或者堆设置过小导致。
`java.lang.OutOfMemoryError: PermGen space` (Java 7 及更早版本) / `java.lang.OutOfMemoryError: Metaspace` (Java 8 及更高版本)	这个区域存储类定义、方法、常量池等元数据。如果加载了大量的类或动态生成类，可能会导致该区域溢出。在 Java 8 之后，PermGen 被 Metaspace 替代，Metaspace 默认使用本地内存，不易出现 OOM，但配置不当或者加载大量类仍然可能导致 OOM。
`java.lang.OutOfMemoryError: GC overhead limit exceeded`	当 JVM 花费了过多的时间进行垃圾回收，但只回收了很少的内存时，会抛出此错误。通常意味着堆中几乎所有对象都是活跃的，GC 无法有效回收。
`java.lang.OutOfMemoryError: Direct buffer memory`	DirectByteBuffer 使用堆外内存，如果分配的 DirectByteBuffer 总大小超过了 `-XX:MaxDirectMemorySize` 设置的值，就会抛出此错误。常见于 NIO 操作。
`java.lang.OutOfMemoryError: Requested array size exceeds VM limit`	尝试分配一个非常大的数组，超过了 JVM 的限制。
`java.lang.OutOfMemoryError: unable to create new native thread`	无法创建新的 native 线程。通常是由于系统资源限制，例如线程数量超过了操作系统允许的最大值。

今天我们重点关注 java.lang.OutOfMemoryError: Java heap space 这种类型，并使用 MAT 来定位堆内存泄漏。

准备工作：获取 Heap Dump

MAT 分析的基础是 Heap Dump，它包含了 JVM 堆内存的快照信息，包括所有对象、它们的大小以及对象之间的引用关系。

获取 Heap Dump 有多种方式：

使用 jmap 命令 (JDK 自带):
```
jmap -dump:format=b,file=heapdump.bin <pid>
```
其中 <pid> 是 Java 进程的 ID。
使用 jcmd 命令 (JDK 自带):
```
jcmd <pid> GC.heap_dump filename=heapdump.bin
```
<pid> 同样是 Java 进程的 ID。
使用 JConsole 或 JVisualVM (JDK 自带):

这些图形化工具提供了友好的界面来生成 Heap Dump。
配置 JVM 参数，让 JVM 在 OOM 时自动生成 Heap Dump:
```
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/heapdump.hprof
```
推荐使用这种方式，可以在 OOM 发生时自动保存现场，方便后续分析。注意 /path/to/heapdump.hprof 需要替换成实际的路径。

使用编程方式手动触发 Heap Dump:

import java.lang.management.ManagementFactory;
import javax.management.MBeanServer;
import com.sun.management.HotSpotDiagnosticMXBean;

public class HeapDump {
    public static void dumpHeap(String filePath, boolean live) throws Exception {
        MBeanServer server = ManagementFactory.getPlatformMBeanServer();
        HotSpotDiagnosticMXBean mxBean = ManagementFactory.newPlatformMXBeanProxy(
            server, "com.sun.management:type=HotSpotDiagnostic", HotSpotDiagnosticMXBean.class);
        mxBean.dumpHeap(filePath, live);
    }

    public static void main(String[] args) throws Exception {
        dumpHeap("heapdump.hprof", true); // Live objects only
    }
}

这种方式允许你在代码中灵活地生成 Heap Dump，例如在特定的业务逻辑发生时。live 参数设置为 true 只会 dump 活跃的对象，false 会 dump所有对象，包括待回收的。

建议： 优先使用 JVM 参数自动生成 Heap Dump，因为 OOM 发生时手动操作可能已经无法进行。其次，使用 jcmd 命令或者编程方式，可以在指定的时间点进行 dump。如果程序已经卡死，只能使用 jmap 工具进行 dump。

MAT 工具介绍与安装

MAT (Memory Analyzer Tool) 是 Eclipse 基金会开发的强大的 Java 堆内存分析工具，可以帮助我们快速定位内存泄漏的根源。

下载： 可以从 Eclipse 官网下载 MAT： https://www.eclipse.org/mat/
安装： MAT 是一个独立的应用程序，下载后解压即可使用。如果安装了 Eclipse IDE，也可以作为插件安装。

使用 MAT 分析 Heap Dump

启动 MAT 并打开 Heap Dump 文件:

启动 MAT 后，选择 "File" -> "Open Heap Dump…"，选择你生成的 Heap Dump 文件 (例如 heapdump.hprof 或 heapdump.bin)。MAT 会自动解析 Heap Dump 文件，这个过程可能需要一些时间，取决于 Heap Dump 文件的大小。
Overview 页面:

打开 Heap Dump 文件后，MAT 会显示一个 Overview 页面，提供了一些基本的统计信息和分析建议。比较重要的是 Leak Suspects 和 Top Components 报告。
- Leak Suspects: MAT 会自动分析 Heap Dump，尝试找出潜在的内存泄漏点，并生成 Leak Suspects 报告。这个报告通常会列出一些可疑的对象和它们的引用链，是排查内存泄漏的起点。
- Top Components: 这个报告会显示占用内存最多的对象类型，可以帮助我们快速找到内存占用的大头。
Histogram 视图:

Histogram 视图显示了 Heap Dump 中每个类及其对象的数量和总大小。可以通过以下步骤使用 Histogram 视图来查找可疑对象：
- 按 Shallow Heap 或 Retained Heap 排序: 点击 "Shallow Heap" 或 "Retained Heap" 列的标题，可以按照对象自身的大小或对象及其引用的对象所占用的总内存大小进行排序。
- 查找数量异常的对象: 关注数量特别多的对象类型，这可能表明存在对象创建过多但未释放的情况。
- 查找 Retained Heap 较大的对象: 关注 Retained Heap 较大的对象，这表明这些对象及其引用的对象占用了大量的内存。
例如，如果我们发现 java.util.ArrayList 对象数量很多，且 Retained Heap 很大，可以怀疑是某个地方的 ArrayList 发生了内存泄漏。
Dominator Tree 视图:

Dominator Tree 视图展示了 Heap Dump 中对象的支配关系。如果对象 A 支配对象 B，意味着所有到达对象 B 的路径都必须经过对象 A。因此，Dominator Tree 可以帮助我们找到内存泄漏的根源，即支配大量其他对象的对象。
- 查找 Retained Size 较大的 Dominator: 关注 Retained Size 较大的 Dominator，这些对象是内存泄漏的潜在根源。
- 展开 Dominator 并查看其引用的对象: 展开 Dominator，查看其引用的对象，可以帮助我们理解为什么这个 Dominator 占用了大量的内存。
OQL (Object Query Language):

MAT 提供了 OQL，一种类似 SQL 的查询语言，可以用来查询 Heap Dump 中的对象。

例如，要查找所有 java.util.ArrayList 对象，可以使用以下 OQL 查询：
```
SELECT * FROM java.util.ArrayList
```
要查找所有 java.lang.String 对象，且长度大于 1000，可以使用以下 OQL 查询：
```
SELECT * FROM java.lang.String s WHERE s.value.length > 1000
```
OQL 非常强大，可以根据各种条件查询对象，帮助我们更精确地定位内存泄漏。可以打开MAT中的 OQL Editor，然后输入查询语句，点击执行。
Path to GC Roots:

找到可疑对象后，可以使用 "Path to GC Roots" 功能来查看对象到 GC Roots 的引用链。 GC Roots 是 JVM 认为必须存活的对象，例如：
- 活动线程的栈帧中的局部变量
- 静态变量
- JNI 引用
如果一个对象可以从 GC Roots 访问到，那么 GC 就不会回收它。因此，通过查看对象到 GC Roots 的引用链，可以找到阻止 GC 回收对象的引用关系，从而定位内存泄漏的根源。
- exclude all phantom/soft/weak references: 排除虚引用，软引用，弱引用，这些引用类型的对象更容易被 GC 回收。

内存泄漏案例分析

让我们通过一个简单的内存泄漏案例来演示如何使用 MAT 分析 Heap Dump。

import java.util.ArrayList;
import java.util.List;

public class MemoryLeakExample {

    private static List<Object> leakedObjects = new ArrayList<>();

    public static void main(String[] args) throws InterruptedException {
        for (int i = 0; i < 100000; i++) {
            Object obj = new Object();
            leakedObjects.add(obj); // 内存泄漏：对象被添加到静态列表中，无法被回收
            Thread.sleep(1); // 模拟业务逻辑
        }
        System.out.println("Finished adding objects.");
        Thread.sleep(60000); // 保持程序运行，方便生成 Heap Dump
    }
}

在这个例子中，我们创建了大量的 Object 对象，并将它们添加到静态列表 leakedObjects 中。由于 leakedObjects 是一个静态变量，它会一直持有这些对象的引用，导致这些对象无法被 GC 回收，从而造成内存泄漏。

运行程序并生成 Heap Dump:

运行上面的代码，等待程序输出 "Finished adding objects." 后，使用 jcmd 或 JConsole 生成 Heap Dump 文件。
使用 MAT 打开 Heap Dump 文件:

启动 MAT，打开生成的 Heap Dump 文件。
查看 Leak Suspects 报告:

MAT 会自动生成 Leak Suspects 报告，可能会提示 MemoryLeakExample.leakedObjects 是可疑的。
查看 Histogram 视图:

在 Histogram 视图中，按 Shallow Heap 排序，可以看到 java.util.ArrayList 和 java.lang.Object 的数量都很多。
查看 Dominator Tree 视图:

在 Dominator Tree 视图中，可以看到 MemoryLeakExample.leakedObjects 占用了大量的内存。

使用 OQL 查询:

可以使用 OQL 查询来查找 MemoryLeakExample.leakedObjects 引用的所有对象：

SELECT * FROM java.lang.Object WHERE this.@address IN (SELECT OBJECT_ID(o) FROM java.util.ArrayList o WHERE o.elementData.@address = (SELECT OBJECT_ID(leakedObjects.elementData) FROM MemoryLeakExample leakedObjects))

这个查询会返回 leakedObjects 引用的所有 Object 对象。

查看 Path to GC Roots:

选中 MemoryLeakExample.leakedObjects 对象，右键选择 "Path to GC Roots" -> "exclude all phantom/soft/weak references"。可以看到 leakedObjects 被静态变量 MemoryLeakExample.leakedObjects 引用，而静态变量是 GC Roots，因此 leakedObjects 及其引用的所有对象都无法被 GC 回收。

通过以上分析，我们可以很容易地定位到内存泄漏的根源：MemoryLeakExample.leakedObjects 静态列表持有了大量对象的引用，导致这些对象无法被 GC 回收。

解决内存泄漏

定位到内存泄漏的根源后，就可以采取相应的措施来解决问题。在上面的例子中，解决方法很简单，只需要在不再需要这些对象时，从 leakedObjects 中移除它们即可。

import java.util.ArrayList;
import java.util.List;

public class MemoryLeakExample {

    private static List<Object> leakedObjects = new ArrayList<>();

    public static void main(String[] args) throws InterruptedException {
        for (int i = 0; i < 100000; i++) {
            Object obj = new Object();
            leakedObjects.add(obj);
            Thread.sleep(1);
        }
        System.out.println("Finished adding objects.");

        // 解决内存泄漏：在不再需要这些对象时，从列表中移除它们
        leakedObjects.clear();

        System.out.println("Cleared leakedObjects.");
        Thread.sleep(60000);
    }
}

常见的内存泄漏模式

除了上面的简单例子，Java 应用中还存在很多其他的内存泄漏模式。了解这些模式可以帮助我们更快地定位和解决内存泄漏问题。

内存泄漏模式	描述	示例
静态集合类	静态集合类（例如静态的 `ArrayList`、`HashMap` 等）会持有对象的引用，如果这些对象不再需要，但没有从集合中移除，就会造成内存泄漏。	`private static List<Object> cache = new ArrayList<>();`
监听器和回调	如果对象注册了监听器或回调函数，但没有在对象销毁时取消注册，监听器或回调函数会持有对象的引用，导致对象无法被 GC 回收。	`button.addActionListener(this);` (如果 `this` 对象不再使用，但 `button` 仍然持有 `this` 的引用)
内部类	非静态内部类会持有外部类的引用。如果内部类的实例长期存活，可能会导致外部类无法被 GC 回收。	`java class Outer { private Inner inner = new Inner(); class Inner {} }`
线程	长时间运行的线程会持有线程局部变量（ThreadLocal）的引用。如果线程池中的线程没有正确清理 ThreadLocal 变量，可能会导致内存泄漏。	`ThreadLocal<Object> threadLocal = new ThreadLocal<>();` (如果线程池中的线程没有在任务结束后调用 `threadLocal.remove()`，可能会导致内存泄漏)
连接池	数据库连接池、HTTP 连接池等资源池会持有连接对象的引用。如果连接没有正确关闭或归还到连接池，可能会导致连接泄漏，最终导致 OOM。	`Connection conn = dataSource.getConnection(); ... conn.close();` (如果 `conn.close()` 没有被调用，连接对象可能会泄漏)
缓存	缓存可以提高性能，但如果缓存中的对象没有设置过期时间或淘汰策略，缓存可能会无限增长，最终导致 OOM。	`Map<String, Object> cache = new HashMap<>();` (如果缓存没有设置过期时间或淘汰策略)
文件和流	打开的文件和流需要在使用完毕后显式关闭。如果没有关闭，操作系统会持有文件句柄，最终可能导致文件句柄耗尽，或者文件占用的内存无法释放。	`FileInputStream fis = new FileInputStream("file.txt"); ... fis.close();` (如果 `fis.close()` 没有被调用，文件资源可能无法释放)
Direct Byte Buffer	使用 `java.nio.DirectByteBuffer` 分配的直接内存如果没有被及时释放，也会造成内存泄漏。因为直接内存不由 JVM 管理，需要手动释放。	`ByteBuffer buffer = ByteBuffer.allocateDirect(1024);` (需要手动释放 direct buffer 占用的内存，可以使用 `sun.misc.Cleaner` 或者其他方式)
不正确的 equals/hashCode	如果自定义对象的 `equals()` 和 `hashCode()` 方法实现不正确，可能会导致对象在 `HashMap`、`HashSet` 等集合中重复添加，造成内存泄漏。	如果 `equals()` 方法只比较对象的引用，而不是比较对象的内容，可能会导致即使两个对象的内容相同，也被认为是不同的对象，从而重复添加到集合中。

最佳实践

代码审查: 定期进行代码审查，重点关注可能存在内存泄漏的地方，例如集合类的使用、监听器的注册和取消注册、资源的管理等。
使用工具: 使用静态代码分析工具（例如 FindBugs、PMD、SonarQube）来检测潜在的内存泄漏问题。
监控: 监控应用的内存使用情况，及时发现内存泄漏的迹象。可以使用 JVM 自带的监控工具（例如 JConsole、JVisualVM），或者使用第三方监控工具（例如 Prometheus、Grafana）。
压力测试: 进行压力测试，模拟高负载场景，可以帮助我们更早地发现内存泄漏问题。
及时释放资源: 确保在使用完毕后及时释放资源，例如关闭文件和流、关闭数据库连接、取消监听器注册等。
谨慎使用静态变量: 避免使用静态集合类来缓存大量对象，如果必须使用，要设置合理的过期时间或淘汰策略。
使用对象池: 对于创建和销毁代价较高的对象，可以使用对象池来复用对象，减少对象创建和销毁的次数。
使用引用队列: 可以使用 ReferenceQueue 来监控对象的回收情况，及时发现内存泄漏问题。
谨慎使用 finalize 方法： finalize 方法的执行时机是不确定的，并且会导致对象回收的延迟，容易导致 OOM。尽量避免使用 finalize 方法。

应对 OOM，需要做的事情

本文主要讲解如何使用 MAT 工具分析 Heap Dump，以定位内存泄漏的原因。但是，仅仅会分析是不够的，还需要采取一些手段来应对 OOM。

增加堆内存： 这是最直接的方法，但只能暂时缓解问题，并不能解决根本原因。如果 OOM 是由内存泄漏引起的，增加堆内存只会延缓 OOM 的发生。
优化代码： 优化代码逻辑，减少不必要的对象创建，避免创建过大的对象。
使用合适的缓存策略： 如果使用了缓存，要设置合理的过期时间或淘汰策略，避免缓存无限增长。
使用更高效的数据结构： 选择合适的数据结构可以减少内存占用。例如，使用 HashSet 代替 ArrayList 来存储不重复的元素。
升级 JVM： 新版本的 JVM 通常会包含一些性能优化和 Bug 修复，可能会改善内存管理。
分析 GC 日志： 分析 GC 日志可以帮助我们了解 GC 的执行情况，例如 GC 的频率、每次 GC 回收的内存大小等，从而判断是否存在内存泄漏。

总结一下

今天我们深入探讨了 Java 应用中 OOM 问题的诊断与解决，重点介绍了如何利用 MAT 工具分析 Heap Dump 来定位内存泄漏的根源。我们学习了如何获取 Heap Dump、MAT 的基本使用方法、常见的内存泄漏模式以及一些最佳实践。记住，预防胜于治疗，代码审查、监控和压力测试是避免 OOM 的关键。