详细记录一下JAVA应用程序服务出现内存溢出的利用MAT分析过程

说明：本次以系统在并发情况下后台出现java.lang.OutOfMemoryError:GC overhead limit exceeded错误来分析整个性能测试分析的一个过程。中间用到的工具包括了：loadrunner 、AWR 报告、jstack、MAT等

1、使用LoadRunner进行50用户的并发测试，先进行2分钟的预热测试，为了系统能用到缓存的地方都先进行缓存，然后进行5分钟的施压测试。

2、在施压5分钟的后半段时间，应用后台开始出现了“java.lang.OutOfMemoryError”的错误信息；

具体错误信息如下：







3、既然出现了OutOfMemoryError的错误信息，一般出现该错误信息都是堆内存的溢出，所以我们需要考虑捕捉一下堆内存的信息，捕捉堆内存的信息有2种方式：

3.1 通过在应用中间件（weblogic、tomcat 等）上加入相应的JVM参数,具体参数如下（加入参数后，系统在出现OutOfMemoryError错误的时候便会自动生成类似java_pid9388.hprof的这样一个文件）：

-Xloggc:D:\heapdump\managed1_gc.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=D:\heapdump

3.2 使用JDK自带的JMAP工具，具体使用方法如下：

第一步：先使用jps.exe命令找到相应的java进程ID，一般找Server PID的；

第二步：jmap.exe-dump:format=b,file=d:\dump\java_pid(第一步查询到的PID号).hprof PID(该地方一定要空格后跟着相应的PID号)

如果只dump heap中的存活对象，则加上选项-live，如下：

jmap.exe -dump:live,format=b,file=/path/heap_pid. hprof 进程ID(PID)

4.使用MAT工具来分析生成的hprof文件内容

4.1打开需要分析的hprof文件：



4.2 在Overview(概述)界面利用饼图的摘要信息来分析哪些对象比较占内存



4.3分析Action部分内容：



4.3.1点击“Leak Suspects”后的结果如下：



4.3.2 在怀疑问题的第点Details



4.3.3查看有问题的的类所引用的所有对象。此时使用鼠标左键点击，然后弹出菜单中进行如下选择：List Objects->with outgoing references

（说明：

图中的Shallow Heap(浅堆)：指对象自身占用内存的大小，不包括它引用的对象。

图中的 Retained Heap(深堆)：指当前对象大小+当前对象可直接或间接引用到对象的大小总和

）





此时可以点击鼠标左键，将sql语句的内容进行拷贝.



此时就找到了问题。

另述：

其实上述第4步找问题的步骤可以简化为在Overview的饼图中通过选择Path to GC Roots 来发现JAVA的内存泄露问题

（Pathto GC Roots：被JVM持有的对象，如当前运行的线程对象，被systemclass loader加载的对象被称为GC Roots， 从一个对象到GC Roots的引用链被称为Pathto GC Roots， 通过分析Pathto GC Roots可以找出JAVA的内存泄露问题，当程序不在访问该对象时仍存在到该对象的引用路径。）