老李案例分享：MAT分析应用程序服务出现内存溢出过程

老李案例分享：MAT分析应用程序服务出现内存溢出过程

 

poptest是国内唯一一家培养测试开发工程师的培训机构，以学员能胜任自动化测试，性能测试，测试工具开发等工作为目标。在poptest的loadrunner的培训中，为了提高学员性能优化的经验，加入了很多服务器方面的优化知识，为性能调优的能力打下基础，通过大量的实战案例的讲解提高学员的实战经验，尽快上手性能测试。（大家对课程感兴趣，请加qq：564202718）

说明：系统在并发情况下后台出现java.lang.OutOfMemoryError:GC overhead limit exceeded错误,利用工具loadrunner 、AWR报告、jstack、MAT等进行性能分析
1、用LoadRunner做50用户并发，先进行2分钟的预热测试，为了系统能用到缓存的地方都先进行缓存，然后进行5分钟的施压测试。（通过loadrunner的controller中设置，大家可以看看loadrunner手册）
2、大约运行7分钟左右，后台出现“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的内存泄露问题，当程序不在访问该对象时仍存在到该对象的引用路径。）