MAT工具使用：Java堆内存分析全攻略

编程并不是一个机械性的工作，而是需要有思考，有创新的工作，语法是固定的，但解决问题的思路则是依靠人的思维，这就需要我们坚持学习和更新自己的知识。今天golang学习网就整理分享《MAT工具详解：Java堆内存分析技巧》，文章讲解的知识点主要包括，如果你对文章方面的知识点感兴趣，就不要错过golang学习网，在这可以对大家的知识积累有所帮助，助力开发能力的提升。

MAT能有效分析Java堆内存并定位内存泄漏。1.获取堆转储文件可通过jmap、jcmd手动生成或OOM时自动触发；2.MAT通过“支配者树”展示对象支配关系，帮助识别大内存占用对象及未释放的引用链；3.“直方图”按实例数量和内存占用排序，揭示异常对象创建和“胖”对象；4.MAT还能发现不必要的对象创建、优化数据结构选择、识别冗余数据、评估缓存策略、发现类加载器泄漏及分析线程栈内存，全面提升内存使用效率。

MAT工具，全称Memory Analyzer Tool，在Java应用出现内存溢出（OOM）或者内存占用异常高时，是深入分析Java堆内存、定位内存泄漏和优化内存使用的利器。它能帮你可视化地探查堆转储文件（heap dump），揭示对象间的引用关系，找出那些不该被保留却依然占据大量内存的对象。

解决方案

要使用MAT进行堆内存分析，首先得有一个堆转储文件（.hprof）。获取这个文件通常有几种方式：

• 手动生成： 最常用的是使用JDK自带的工具，比如jmap或jcmd。例如，jmap -dump:format=b,file=heap.hprof 可以为指定进程ID生成堆转储。我个人更倾向于jcmd GC.heap_dump ，感觉它在某些场景下更稳定一些。
• OOM时自动生成： 在JVM启动参数中添加-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dump，这样当应用程序发生OOM时，JVM会自动在指定路径生成堆转储文件。这招特别管用，因为OOM往往是难以复现的生产问题。

有了.hprof文件后，启动MAT工具（通常是Eclipse插件或独立版本）。打开文件，MAT会进行解析并生成一个初步的概览报告。这个报告很关键，通常会直接指出“内存泄漏嫌疑报告”（Leak Suspects Report），这往往是解决问题的起点。如果报告没直接指出，或者你觉得需要更深入的分析，那么就要自己动手了。我会从“支配者树”（Dominator Tree）和“直方图”（Histogram）开始，它们是MAT最核心的两个视图。

为什么我的应用内存总是飙升，MAT能帮我找到症结吗？

当然能。这几乎是MAT最核心的价值所在。内存飙升通常不是一个单一的原因，它可能是内存泄漏、无效缓存、数据结构使用不当，甚至是一些你没注意到的第三方库行为。MAT能帮你把这些“黑箱”打开，看到底是什么在占用内存。

我遇到过好几次，应用在生产环境跑着跑着，内存就一点点往上涨，最后直接OOM。这时候，MAT就像一个侦探，通过分析堆转储文件，它能：

• 定位内存泄漏的根源： 这是最常见的场景。MAT的“支配者树”视图能清晰地展示哪些对象“支配”了大量的内存。当你发现一个本应被垃圾回收的对象（比如一个旧的用户会话、一个已关闭的数据库连接）却依然被某个全局变量或静态集合引用着，那么恭喜你，你找到泄漏点了。MAT的“Path to GC Roots”功能尤其强大，它能帮你追溯到为什么这个对象没有被回收，是哪个GC Root（比如线程栈、静态字段）在引用它。我通常会沿着这条路径一路看下去，直到找到那个“不该有的引用”。
• 识别“胖”对象： 有时候不是泄漏，而是你无意中创建了太多巨大对象。比如一个List，里面每个byte[]都几十兆。MAT的“直方图”会告诉你哪些类的实例数量最多，或者哪些类的实例总大小最大。你可能发现某个自定义对象实例数量异常多，或者某个缓存对象占用了绝大部分内存。
• 揭示无效缓存： 很多时候我们为了性能会使用缓存，但如果缓存策略不当，比如只增不减的HashMap，它就会变成一个“内存黑洞”。MAT能帮你看到这个HashMap到底存了多少对象，这些对象又有多大。这会促使你去思考，是不是该引入LRU或其他淘汰策略了。

MAT的“支配者树”和“直方图”到底有什么用，我该怎么看？

这两个视图是MAT分析的基石，理解它们至关重要。

• 支配者树（Dominator Tree）：
  • 作用： 这个视图展示了内存中对象的支配关系。如果对象A支配对象B，意味着从任何GC根到B的路径都必须经过A。换句话说，如果A被垃圾回收了，那么B（以及所有被B独占引用的对象）也会被回收。它能让你快速找到那些“大胖子”——如果一个对象在支配者树中排在前面，且其“Retained Heap”（保留堆）非常大，那么它就是内存占用的大户。
  • 怎么看： 打开支配者树视图，你会看到一个树状结构，根节点通常是JVM的各种内部结构。向下展开，你会看到各种对象实例，它们按保留堆大小降序排列。关注那些异常大的节点，点进去看它引用的子对象。我一般会特别留意那些集合类（ArrayList、HashMap等），因为它们常常是内存泄漏的“容器”。如果一个HashMap占据了几个G的内存，那问题多半出在它里面存了什么不该存的东西。
• 直方图（Histogram）：
  • 作用： 直方图列出了堆中所有类的实例数量和内存占用（浅堆和保留堆）。浅堆（Shallow Heap）是对象自身占用的内存大小，不包括它引用的对象。保留堆（Retained Heap）是如果该对象被垃圾回收，能够释放的内存总量。
  • 怎么看： 在直方图视图中，你可以按实例数量或保留堆大小进行排序。通过它，你能一眼看出哪些类的实例数量异常多，或者哪些类的实例虽然数量不多但单个对象非常大。比如，你可能发现有几百万个String对象，这可能意味着你没有充分利用字符串常量池，或者存在大量的字符串拼接操作。又比如，你看到某个自定义的MyBigData类，虽然只有几百个实例，但每个实例的保留堆都非常大，那你就知道该去优化MyBigData的内部结构了。我经常用它来快速扫描，看看有没有哪个类的实例数量或者总大小远超预期，这往往是性能瓶颈或内存问题的信号。

除了查找内存泄漏，MAT还能给我哪些优化内存的思路？

MAT的价值远不止于发现内存泄漏，它能提供更全面的内存优化视角：

• 发现不必要的对象创建： 有时候代码并没有泄漏，但却在短时间内创建了大量临时对象，导致频繁的GC，影响性能。通过直方图，你可以看到哪些类的实例数量非常庞大，但它们的保留堆却很小（意味着它们没有被长期引用）。这可能提示你考虑对象池、重用对象，或者减少不必要的中间对象创建。比如，一个频繁调用的方法中创建了大量的String或Integer对象，这就可以优化。
• 优化数据结构选择： 同样是存储数据，ArrayList和LinkedList在内存占用和访问效率上都有区别。HashMap和ConcurrentHashMap的内部实现也不同。MAT能让你看到这些数据结构内部的实际内存占用情况，比如HashMap的内部数组和Entry对象。这可以引导你重新评估当前的数据结构选择是否是最优的。我曾通过MAT发现，某个HashMap的加载因子设置不合理，导致内部数组频繁扩容，浪费了大量内存。
• 识别冗余数据： 有些数据可能在内存中存在多份副本，或者存储了实际业务不需要的冗余信息。MAT的OQL（Object Query Language）功能非常强大，你可以用类似SQL的语法查询堆中的对象。比如，你可以查询所有String对象，并按内容分组，看看是否有大量重复的字符串，这可能意味着可以考虑字符串去重（String Deduplication，Java 8u20+有此功能）。
• 评估缓存策略： 缓存是提升性能的常用手段，但如果缓存中的对象从未被清理，就会变成内存负担。通过MAT，你可以看到缓存对象（如ConcurrentHashMap）的实际大小和其中存储的元素。这能帮助你判断缓存是否过大，或者是否需要引入更激进的淘汰策略（如LRU、LFU）。
• 发现类加载器泄漏： 这是一个比较隐蔽的问题，通常发生在热部署或者插件化应用中。当旧的类加载器没有被正确卸载，它所加载的所有类和这些类的静态字段就会一直占用内存。MAT可以帮助你识别出多个同名类被不同类加载器加载的情况，这通常是类加载器泄漏的信号。
• 分析线程栈内存： 虽然MAT主要关注堆内存，但它也能显示线程对象和它们的栈帧。如果你看到大量的线程处于WAITING或BLOCKED状态，并且每个线程栈都占用了不小的内存，这可能提示你线程池配置不合理，或者存在死锁/长时间等待的问题。虽然这不是直接的堆内存泄漏，但也是内存使用效率的问题。

今天关于《MAT工具使用：Java堆内存分析全攻略》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！