在排查 TongWeb、Tomcat、Spring Boot 等 Java 服务的内存问题时经常会遇到这样的情况JVM 内存越来越高 ↓ Full GC 越来越频繁 ↓ GC 后内存仍然降不下来 ↓ 最终 OutOfMemoryError这时候仅仅通过top、jstat查看 JVM 内存只能知道“内存有问题”却很难知道到底是什么对象占用了内存。这时候就可以使用Eclipse Memory AnalyzerMAT。简单来说MAT就是一款专门用来分析 Java Heap Dump 的工具可以帮助我们找到占内存最多的对象以及这些对象为什么一直没有被 GC 回收。最主要的是完全免费不需要进行pojie等操作。MAT 主要用来解决什么问题MAT 最常见的使用场景主要有以下几种1. Java 服务频繁 OOM例如日志出现java.lang.OutOfMemoryError: Java heap space可以在 JVM OOM 后生成的 Heap Dump 中寻找问题。2. JVM 内存持续上涨例如启动2G 运行一天3G 运行三天5G 运行一周7G而且 Full GC 之后内存仍然很高就需要重点怀疑对象没有正常释放。3. Full GC 频繁如果发现 JVM 不断进行 Full GCFull GC Full GC Full GC但是回收效果越来越差也可以通过 Heap Dump 分析到底是什么对象占用了堆内存。4. 怀疑内存泄漏例如缓存没有清理 ThreadLocal 使用不当 静态 Map 持有大量对象 Session 保存大量数据 Web 应用重复部署后 ClassLoader 没有释放这些问题都可以通过 MAT 进一步分析。MAT 的整体排查思路第一次使用 MAT不需要把所有功能都学会。记住下面这条路线就够了第一步找到服务器上的 Java 进程首先登录服务器。执行jps -l例如[rootserver ~]# jps -l 12345 org.apache.catalina.startup.Bootstrap 13579 sun.tools.jps.Jps这里12345就是我们需要分析的 Java 进程 PID。第二步检查磁盘空间Heap Dump 可能非常大。例如JVM 最大堆8G生成出来的.hprof文件可能达到几个 GB。所以生成之前建议先执行df -h确认目标磁盘空间足够。例如Filesystem Size Used Avail Use% /dev/sda3 100G 55G 45G 56%第三步生成 Heap Dump现在假设 Java PID 是12345推荐使用jcmdjcmd 12345 GC.heap_dump /data/dump/tongweb.hprof也可以使用jmapjmap -dump:formatb,file/data/dump/tongweb.hprof 12345生成成功后会得到tongweb.hprof这个文件就是后面 MAT 分析的对象。确认文件是否生成成功执行ls -lh /data/dump/tongweb.hprof例如-rw------- 1 root root 4.2G Sep 3 13:20 tongweb.hprof这里重点看文件大小。如果发现4.2G说明这个文件比较大后续下载和 MAT 分析都需要一定时间。第四步把 Heap Dump 下载到本地服务器上的文件一般不建议直接在服务器上分析。通常是服务器 ↓ 生成 hprof ↓ 下载 ↓ 自己的电脑 ↓ MAT 分析例如 Mac/Linux 可以使用scp root192.168.1.100:/data/dump/tongweb.hprof .如果 SSH 使用其他端口scp -P 2222 root192.168.1.100:/data/dump/tongweb.hprof .也可以使用 Xftp、WinSCP、SFTP 等工具传输。第五步使用 MAT 打开 Heap Dump打开 Eclipse Memory Analyzer。你现在看到的这个界面就是 MAT 的主界面。然后点击File ↓ Open Heap Dump选择tongweb.hprof也可以直接点击Open a Heap Dump然后选择.hprof文件。打开之后先看 OverviewHeap Dump 加载完成后MAT 会展示整体信息。这里可以先看看对象数量 Class 数量 Class Loader 堆内存情况不用一开始就研究所有数据。先建立一个概念这个 Heap Dump 记录的到底是一个什么样的 JVM 内存现场。第一项重点分析Leak SuspectsMAT 通常会提供Leak Suspects可以理解成MAT 根据当前 Heap Dump 自动找出来的可疑内存占用点。例如Problem Suspect 1 One instance of xxx retains a large amount of memory这时候可以继续点击进去查看具体对象和引用关系。不过要注意Leak Suspects 标记出来的对象不一定就是内存泄漏。比如一个正常的大缓存本身就可能占用几个 GB。所以还需要继续分析。第二项重点分析Histogram找到HistogramHistogram 可以简单理解成按照 Java 类统计对象数量和内存占用。例如Class Name Objects Shallow Heap ------------------------------------------------------- java.lang.String 3000000 120 MB byte[] 1000000 800 MB java.util.HashMap$Node 900000 30 MB com.xxx.User 500000 40 MB这里重点观察两个问题对象数量是不是异常例如User500万 Order300万 String1000万如果业务实际上只有几十万用户这就值得调查。哪些对象占用内存最多尤其关注byte[] char[] String HashMap ConcurrentHashMap 业务自己的对象第三项重点分析Dominator Tree如果想进一步找到底是谁“占住”了大量内存可以打开Dominator Tree重点关注Retained Heap例如com.xxx.Cache 3.2 GB HashMap 2.8 GB com.xxx.UserManager 1.5 GB byte[] 900 MB这时候com.xxx.Cache就值得重点检查。因为它自己可能只占几十 MB但它引用了大量其他对象最终导致Retained Heap 3.2 GB这也是 MAT 排查内存问题时非常重要的一个指标。最后一个关键分析Path to GC Roots假设我们发现com.xxx.User占用了大量内存。接下来最关键的问题是为什么这些 User 一直没有被 GC 回收可以右键对象找到Path to GC Roots然后查看引用链。例如GC Root ↓ Thread ↓ ThreadLocalMap ↓ ThreadLocal ↓ User或者GC Root ↓ Static Field ↓ Cache ↓ HashMap ↓ User这时候就开始接近真正的问题了。exclude all phantom/weak/soft etc. references【排查泄漏首选】只保留强引用屏蔽缓存类弱引用干扰。include all references全部引用都展示会出来大量 WeakHashMap 等弱引用信息很乱。实际排查时主要关注哪些对象如果是生产环境 Java 应用我一般会重点关注这些类型重点检查HashMap是否无限增长ConcurrentHashMap是否存在无上限缓存String数量是否异常byte[]是否存在大量数据、文件、请求内容Thread是否存在异常线程ThreadLocal是否长期持有业务对象Session是否保存了大量数据ClassLoader是否存在重复部署导致无法释放业务对象是否数量异常、长期存活特别是看到Retained Heap 很大不要马上判断是泄漏。应该继续问谁引用它 为什么引用 这个对象正常情况下应该存在多久 有没有清理机制一个简单的实际案例假设客户反馈TongWeb 运行几天以后内存越来越高最后 OOM。我们可以按照下面的方式排查最终可能发现某个 static ConcurrentHashMap ↓ 不断 put 数据 ↓ 没有过期机制 ↓ 对象越来越多 ↓ Retained Heap 持续增长 ↓ Full GC 无法回收 ↓ 最终 OOM这才是一次比较完整的内存问题排查。还有一个非常实用的方法对比多个 Heap Dump如果问题是内存随着运行时间不断上涨不要只生成一个 Heap Dump。可以在不同时间分别生成dump-01.hprof dump-02.hprof dump-03.hprof例如第一次JVM 使用 3G 第二次JVM 使用 5G 第三次JVM 使用 7G然后分别使用 MAT 分析。重点比较哪些对象越来越多 哪些对象 Retained Heap 不断增加 哪些对象始终没有被释放这种方式往往比只分析一次 Heap Dump 更容易发现真正的内存泄漏。小结一下如果刚开始接触 MAT不需要一次把所有功能都学会。先记住这几个Heap Dump ↓ Leak Suspects ↓ Histogram ↓ Dominator Tree ↓ Path to GC Roots分别解决Heap Dump → 保存 JVM 某一时刻的内存现场 Leak Suspects → MAT 帮你找可疑点 Histogram → 看什么对象最多 Dominator Tree → 看谁占住了最多内存 Path to GC Roots → 看为什么这些对象一直没有被回收最终目的不是“看懂 MAT 里的所有数据”而是回答三个问题谁占用了内存为什么占这么多为什么 GC 没有把它回收