一文教会你使用jmap和MAT进行堆内存溢出分析
作者:没头脑遇到不高兴
jmap:Java内存映像工具
jmap(Memory Map for Java)命令用于生成堆转储快照(一般称为heapdump或dump文件)。另外,还有几种方式获取dump文件:使用JVM参数选项-XX:+HeapDumpOnOutOfMemoryError参数,可以让虚拟机在OOM异常出现之后自动生成dump文件,通过-XX:HeapDumpPath=path 设置dump文件路径(有时候dump文件比较大的时候可能无法自动导出,这时候就需要使用jmap -dump手动导出了);通过-XX.+HeapDumpOnCtrlBreak参数则可以使用[Ctrl]+[Break]键让虚拟机生成dump文件;又或者在Linux系统下通过Kill -3命令发送进程退出信号“吓唬”一下虚拟机,也能拿到dump文件。
jmap的作用并不仅仅是为了获取dump文件,它还可以查询finalize执行队列、Java堆和永久代的详细信息,如空间使用率、当前用的是哪种收集器等。和jinfo命令一样,jmap有不少功能在Windows平台下都是受限的,除了生成dump文件的-dump选项和用于查看每个类的实例、空间占用统计的-histo选项在所有操作系统都提供之外,其余选项都只能在Linux/Solans下使用。其官方文档地址为:https://docs.oracle.com/javase/8/docs/technotes/tools/unix/jmap.html
jmap命令格式:jmap [option] vmid
C:\Users\Administrator>jmap -help Usage: jmap [option] <pid> (to connect to running process) jmap [option] <executable <core> (to connect to a core file) jmap [option] [server_id@]<remote server IP or hostname> (to connect to remote debug server) where <option> is one of: <none> to print same info as Solaris pmap -heap to print java heap summary -histo[:live] to print histogram of java object heap; if the "live" suboption is specified, only count live objects -clstats to print class loader statistics -finalizerinfo to print information on objects awaiting finalization -dump:<dump-options> to dump java heap in hprof binary format dump-options: live dump only live objects; if not specified, all objects in the heap are dumped. format=b binary format file=<file> dump heap to <file> Example: jmap -dump:live,format=b,file=heap.bin <pid> -F force. Use with -dump:<dump-options> <pid> or -histo to force a heap dump or histogram when <pid> does not respond. The "live" suboption is not supported in this mode. -h | -help to print this help message -J<flag> to pass <flag> directly to the runtime system
option选项介绍如下:
选项 | 作用 |
---|---|
-heap | 显示Java堆详细信息,使用哪种收集器、参数配置、分代状况等。只在Linux/Solaris平台下有效。 |
-histo[:live] | 对于每个Java类,打印对象的数量、字节大小的内存大小以及完全限定的类名。jvm内部类名以星号(*)前缀打印。如果使用 -histo:live,则仅计算存活的对象。 |
-clstats |
打印Java堆的类加载器统计信息。对于每个类加载器,都会打印其名称、活动程度、地址、父类加载器以及已装入的类的数量和大小。 |
-finalizerinfo | 显示在F-Queue中等待Finalizer线程执行finalize方法的对象。只在Linux/Solaris平台下有效 |
-dump:<dump-options> | 生成Java堆转储快照,格式为 -dump:[live,]format=b,file=<filename>,其中live子参数说明是否只dump出存活的对象 |
-F | 当虚拟机进程对-dump选项没有响应时,可使用这个选项强制生成dump快照。只在Linux/Solaris平台下有效 |
注意:使用 jmap -histo:live <pid>或者jmap -dump:live,format=b,file=<filename> <pid> 都会触发FullGC
使用例:jmap -heap在JDK1.7中打印结果如下:可以看到永久代Perm区
[root@wkp ~]# jmap -heap 3177 Attaching to process ID 3177, please wait... Debugger attached successfully. Server compiler detected. JVM version is 24.80-b11 using thread-local object allocation. Parallel GC with 2 thread(s) Heap Configuration: MinHeapFreeRatio = 0 MaxHeapFreeRatio = 100 MaxHeapSize = 2099249152 (2002.0MB) NewSize = 1310720 (1.25MB) MaxNewSize = 17592186044415 MB OldSize = 5439488 (5.1875MB) NewRatio = 2 SurvivorRatio = 8 PermSize = 21757952 (20.75MB) MaxPermSize = 85983232 (82.0MB) G1HeapRegionSize = 0 (0.0MB) Heap Usage: PS Young Generation Eden Space: capacity = 371720192 (354.5MB) used = 330326552 (315.0239486694336MB) free = 41393640 (39.476051330566406MB) 88.86430145823232% used From Space: capacity = 5242880 (5.0MB) used = 5073520 (4.8384857177734375MB) free = 169360 (0.1615142822265625MB) 96.76971435546875% used To Space: capacity = 47710208 (45.5MB) used = 0 (0.0MB) free = 47710208 (45.5MB) 0.0% used PS Old Generation capacity = 159383552 (152.0MB) used = 113434496 (108.1795654296875MB) free = 45949056 (43.8204345703125MB) 71.17076673005757% used PS Perm Generation capacity = 42991616 (41.0MB) used = 42852648 (40.867469787597656MB) free = 138968 (0.13253021240234375MB) 99.67675557950648% used 19120 interned Strings occupying 2253456 bytes.
jmap -heap在JDK1.8中打印结果如下:可以看到了元空间,没有了永久代
[root@wkp ~]# jmap -heap 8543 Attaching to process ID 8543, please wait... Debugger attached successfully. Server compiler detected. JVM version is 25.171-b11 using thread-local object allocation. Parallel GC with 4 thread(s) Heap Configuration: MinHeapFreeRatio = 0 MaxHeapFreeRatio = 100 MaxHeapSize = 2051014656 (1956.0MB) NewSize = 42991616 (41.0MB) MaxNewSize = 683671552 (652.0MB) OldSize = 87031808 (83.0MB) NewRatio = 2 SurvivorRatio = 8 MetaspaceSize = 21807104 (20.796875MB) CompressedClassSpaceSize = 1073741824 (1024.0MB) MaxMetaspaceSize = 17592186044415 MB G1HeapRegionSize = 0 (0.0MB) Heap Usage: PS Young Generation Eden Space: capacity = 28311552 (27.0MB) used = 13137328 (12.528732299804688MB) free = 15174224 (14.471267700195312MB) 46.402712221498845% used From Space: capacity = 524288 (0.5MB) used = 98304 (0.09375MB) free = 425984 (0.40625MB) 18.75% used To Space: capacity = 524288 (0.5MB) used = 0 (0.0MB) free = 524288 (0.5MB) 0.0% used PS Old Generation capacity = 76021760 (72.5MB) used = 27335480 (26.06914520263672MB) free = 48686280 (46.43085479736328MB) 35.957441658809266% used 24117 interned Strings occupying 2830304 bytes.
通过命令 jmap -dump:live,format=b,file=/usr/local/heap.hprof 12632 就可以生成dump文件了
[root@wkp ~]# jmap -dump:live,format=b,file=/usr/local/heap.hprof 12632 Dumping heap to /usr/local/heap.hprof ... Heap dump file created
好了,介绍了dump文件的生成,下面分析工具MAT就要粉墨登场了。
MAT
MAT(Eclipse Memory Analyzer)是一种快速且功能丰富的Java堆分析器,它帮助查找内存泄漏并减少内存消耗。使用内存分析器分析具有数亿个对象的高效堆转储,快速计算对象的保留大小,查看谁在阻止垃圾收集器收集对象,运行报告以自动提取泄漏嫌疑。官网地址https://www.eclipse.org/mat,下载地址为https://www.eclipse.org/mat/downloads.php。我们可以在下载页面看到:MAT可以独立运行,也可以通过插件的形式在Eclipse中安装使用,具体的安装过程就不再这里介绍了,我是下载的独立运行的程序包。
MAT的官方文档地址https://help.eclipse.org/2019-09/index.jsp?topic=/org.eclipse.mat.ui.help/welcome.html, 里面做了很详细的介绍。
下面我们通过一个例子,来介绍一下MAT的使用。我们创建一个springboot应用程序,controller代码如下:通过往成员变量userList中一直添加user对象来构造堆内存溢出。controller中heap方法的注释中表明了运行时添加的JVM参数 -Xmx32M -Xms32M -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./ 设置堆内存最大为32兆,当内存溢出时自动在当前目录生成dump文件。
@RestController public class MemoryController { private List<User> userList = new ArrayList<User>(); /** *-Xmx32M -Xms32M -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./ */ @GetMapping("/heap") public String heap() { int i=0; while(true){ userList.add(new User(i++, UUID.randomUUID().toString())); } } }
User类代码如下:
public class User { private int id; private String name; public User(int id, String name) { super(); this.id = id; this.name = name; } //省略set,get方法 }
设置JVM参数运行如下:
然后启动springboot应用,启动端口为9999,访问 http://localhost:9999/heap 后触发堆内存溢出,可以看到控制台输出已经生成了dump文件java_pid16500.hprof
java.lang.OutOfMemoryError: GC overhead limit exceeded
Dumping heap to ./\java_pid11524.hprof ...
Heap dump file created [44602961 bytes in 0.239 secs]
Exception in thread "http-nio-9999-exec-3" java.lang.OutOfMemoryError: GC overhead limit exceeded
下面我们打开MAT,选择File——>Open Heap Dump,打开我们上面生成的dump文件
点击finish后,会看到如下界面:
从上图可以看到它的主要功能:
- 1. Histogram可以列出内存中的对象,对象的个数以及大小(对象大小的单位是byte)。
- 2. Dominator Tree可以列出对象占用的大小及百分比等。
- 3.Top consumers通过图形列出最大的对象。
- 4.Leak Suspects通过MA自动分析,会出具内存泄漏可能产生的原因的报告。
在MAT的图表中,有一些常用选项:
- list objects -- with outgoing references : 查看这个对象持有的外部对象引用。
- list objects -- with incoming references : 查看这个对象被哪些外部对象引用。
- show objects by class -- with outgoing references :查看这个对象类型持有的外部对象引用
- show objects by class -- with incoming references :查看这个对象类型被哪些外部对象引用
- paths to gc root : 显示不同类型引用(强引用、弱引用、虚引用、软引用 )到跟节点的路径。
- merge shorest path to gc root : 合并最短路径到root节点
- Shallow size:就是对象本身占用内存的大小,不包含其引用的对象,也就是对象头加成员变量(不是成员变量的值)的总和。
- Retained size:是该对象自己的shallow size,加上从该对象能直接或间接访问到对象的shallow size之和。换句话说,retained size是该对象被GC之后所能回收到内存的总和。这个是需要重点关注的,一般这个Retained size比较大的对象就是跟内存溢出相关的。
对于上图左边的object1,object1大小就是shallow size,object1及所有蓝色对象就是该对象直接或是间接引用的就是retained size。右图中object4还被gc roots引用到,那么retained size就不包含这个。
Top consumers视图
Top consumers如下图:这里显示了内存中最大的对象有哪些,他们对应的类是哪些,类加载器classloader是哪些。可以看到MemoryController类的对象占用了15MB的堆内存,占比达50%多,这是很不正常的。我这里只截图了关于对象相关的,后面还会有类,类加载器,包相关的信息,就不一一截图了,大家可以自己看一下。
Leak Suspects视图
Leak Suspects(内存泄露分析)如下图:内存泄露分析报告怀疑有两个内存泄露嫌疑,显示我们看到Problem Suspect 1显示MemoryController类对象占用了57.74%的内存,这部分内存积聚在一个Object[]中。
接下来我们点击Problem Suspect 1 中的Details查看详情,可以看到如下所示:通过图示也可以看到MemoryController中的userList占用了15兆多的内存,userList中存储的是user对象,这些user对象都存储在ArrayList中的Object[] elementData 中,查看ArrayList源码就知道了。另外,还可以看到是在org.apache.tomcat.util.threads.TaskThread @ 0xfecb3220 http-nio-9999-exec-3 Thread 这个线程中创建的。
transient Object[] elementData; // non-private to simplify nested class access /** * Constructs an empty list with an initial capacity of ten. */ public ArrayList() { this.elementData = DEFAULTCAPACITY_EMPTY_ELEMENTDATA; }
通过点击右键,可以通过List objects-with outgoing references : 查看这个对象持有的外部对象引用。
Histogram视图
Histogram视图中我们可以使用正则表达式进行删选,我是按照com.wkp进行筛选的,可以看到有111305个user对象,我们通过merge shorest path to gc roots可以查找user对象的GC Roots,通过exclude all phantom/weak/soft etc.references去排除掉虚引用、弱引用、软引用等,
查看GC Roots如下, 可以看到http-nio-9999-exec-3 Thread 这个线程就是GC Roots,就是因为这个线程中userList中存储了太多的user对象导致堆内存撑爆了,才会出现内存溢出的。
Dominator Tree视图
Dominator Tree可以列出对象占用空间大小及百分比等信息。可以看到跟上面的视图类似,可以看到MemoryController对象的Shallow Heap才16byte,但是Retained Heap却达到了15MB多,这是极其不正常的,这种就是内存泄露的重点怀疑对象。
关于jmap和MAT的使用就先介绍到这里,因为这个内存溢出是我们手动构造出来的,查找比较简单,真的到了生产上面需要我们仔细排除。总的来说查找内存溢出的原因,总结如下两点:
- 1.首先看retained size最大的那些数据,一般看内存都是想解决内存泄漏问题,可以通过Top Consumers或者是donimator tree等actions。
- 2.找到最大的数据后,通过list objects -- with outgoing references 查看具体持有了哪些对象。
到此这篇关于一文教会你使用jmap和MAT进行堆内存溢出分析的文章就介绍到这了,更多相关jmap MAT 堆内存溢出 内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!