堆转储 探索

一、什么是堆转储（Heap Dump）？

堆转储（Heap Dump）是 JVM 在某一时刻整个堆内存的快照，以.hprof文件形式保存。它包含：

• 所有存活对象的实例
• 对象的类信息
• 对象之间的引用关系
• 对象占用的内存大小

💡 内存泄漏的本质：本该被回收的对象，因被意外强引用而无法释放，持续占用堆内存。堆转储能让你“看到”这些不该存在的对象及其引用链。

二、如何生成堆转储文件？

方法 1：自动触发（推荐用于生产）

# JVM 启动参数：当发生 OOM 时自动生成 heap dump -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dumps/

方法 2：手动触发（开发/测试环境）

# 使用 jcmd（JDK 自带） jcmd <pid> GC.run_finalization jcmd <pid> VM.gc jcmd <pid> GC.run # 可选：先触发一次 GC，排除可回收对象干扰 jcmd <pid> VM.heap_dump /tmp/app.hprof # 或使用 jmap（已 deprecated，但仍可用） jmap -dump:live,format=b,file=/tmp/app.hprof <pid>

✅ 建议加live参数：只 dump 存活对象，减少文件体积，聚焦真实问题。

三、分析堆转储的核心思路

要定位内存泄漏，关键在于回答三个问题：

1. 哪些对象占用了大量内存？
2. 这些对象为什么没有被 GC 回收？
3. 是谁在持有对它们的引用？（即“GC Roots 引用链”）

四、常用分析工具

✅ 推荐使用Eclipse MAT（免费开源）：https://www.eclipse.org/mat/

五、实战分析步骤（以 Eclipse MAT 为例）

步骤 1：打开.hprof文件

MAT 会自动解析并生成Leak Suspects Report（内存泄漏嫌疑报告）—— 这是第一线索！

步骤 2：查看 Dominator Tree（支配树）

• Dominator Tree显示“如果移除某个对象，能释放多少内存”。
• 按Retained Heap（保留堆大小）排序，找出“大头”。

📌 Retained Heap ≠ Shallow Heap：

• Shallow Heap：对象自身占用内存（不含引用对象）
• Retained Heap：对象 + 所有仅被它引用的对象总内存 →这才是关键指标！

步骤 3：分析 GC Roots 引用链

• 右键可疑对象 →"Path To GC Roots" → "exclude weak/soft references"
• 查看强引用链：从 GC Root（如静态变量、线程栈）到该对象的路径
• 找出本不该持有引用的“罪魁祸首”

六、经典内存泄漏案例 + 代码演示

🧩 案例 1：静态集合缓存未清理

public class MemoryLeakExample { // 静态集合 = GC Root！所有加入的对象都无法被回收 private static final List<String> CACHE = new ArrayList<>(); public static void main(String[] args) throws InterruptedException { while (true) { CACHE.add("Leak data: " + System.currentTimeMillis()); Thread.sleep(100); } } }

分析过程：

1. 生成 heap dump（OOM 后或手动）
2. MAT 中发现ArrayList占用巨大 Retained Heap
3. 查看 Path to GC Roots → 发现被MemoryLeakExample.CACHE（静态字段）引用
4. 结论：静态缓存无限增长，应改用 LRU 缓存或定期清理

🧩 案例 2：监听器/回调未注销

public class EventManager { private static final List<EventListener> listeners = new ArrayList<>(); public static void addListener(EventListener listener) { listeners.add(listener); // 添加后从未 remove！ } // 忘记提供 removeListener() 方法 } // 某个 Activity 或临时对象注册了监听器 public class TempComponent { public TempComponent() { EventManager.addListener(this::onEvent); } private void onEvent() { /* ... */ } }

分析过程：

• 堆中存在大量TempComponent实例
• 引用链：EventManager.listeners→TempComponent
• 根本原因：监听器注册后未反注册，导致临时对象无法回收

🧩 案例 3：ThreadLocal 未清理（尤其在线程池中）

public class BadThreadLocal { private static final ThreadLocal<byte[]> local = ThreadLocal.withInitial(() -> new byte[1024 * 1024]); // 1MB public void process() { local.get(); // 使用 // 忘记调用 local.remove()！ } } // 在线程池中反复调用 ExecutorService pool = Executors.newFixedThreadPool(10); while (true) { pool.submit(() -> new BadThreadLocal().process()); }

分析过程：

• 堆中存在大量byte[]数组
• 引用链：Thread.threadLocals→ThreadLocalMap→byte[]
• 结论：ThreadLocal在线程复用场景下必须remove()，否则内存泄漏！

七、高级技巧：使用 OQL（Object Query Language）

MAT 支持类似 SQL 的查询语言，快速筛选对象：

-- 查找所有 ArrayList 实例，按 retained size 降序 SELECT * FROM java.util.ArrayList ORDER BY retainedHeapSize DESC -- 查找包含特定字符串的对象 SELECT * FROM java.lang.String s WHERE s.value.toString().contains("Leak")

八、预防内存泄漏的最佳实践

1. 避免滥用静态集合：如必须使用，考虑WeakHashMap或设置容量上限。
2. 及时注销监听器/回调：遵循“谁注册，谁注销”原则。
3. ThreadLocal 用完务必remove()。
4. 资源类（如 InputStream、Connection）必须 try-with-resources 或 finally 关闭。
5. 定期压测 + 监控堆内存趋势（如 Prometheus + Grafana）。

总结