使用MAT工具进行内存溢出定位及分析.docx

内存溢出监控及分析问题所在一、 内存溢出&内存泄漏的名词解释内存溢出（out of memory）：就是你要求分配的内存超出了系统能给你的，系统不能满足需求，于是产生溢出。内存泄露（memory leak）：是指程序在申请内存后，无法释放已申请的内存空间，一次内存泄露危害可以忽略，但内存泄露堆积后果很严重，无论多少内存,迟早会被占光。二、 何时会抛出内存溢出错误何时会抛出Out Of MemoryException，并不是内存被耗空的时候才抛出 JVM98%的时间都花费在内存回收 每次回收的内存小于2% 满足这两个条件将触发OutOfMemoryException，这将会留给系统一个微小的间隙以做一些Down之前的操作，比如手动打印Heap Dump。Q：为什么崩溃前垃圾回收的时间越来越长？A：根据内存模型和垃圾回收算法，垃圾回收分两部分：内存标记、清除（复制），标记部分只要内存大小固定时间是不变的，变的是复制部分，因为每次垃圾回收都有一些回收不掉的内存，所以增加了复制量，导致时间延长。所以，垃圾回收的时间也可以作为判断内存泄漏的依据Q：为什么Full GC的次数越来越多？A：因此内存的积累，逐渐耗尽了年老代的内存，导致新对象分配没有更多的空间，从而导致频繁的垃圾回收Q：为什么年老代占用的内存越来越大？A：因为年轻代的内存无法被回收，越来越多地被Copy到年老代三、 内存溢出的一些现象现象1、后台日志会报错- Out of Memory当Java程序申请内存，超出VM可分配内存的时候，首先可能会垃圾回收()，如果完还是不够，或者申请的直接超够可能有的，就会抛出内存溢出异常。从规范中我们可以得到，以下几种异常：java.lang.StackOverflowError:（很少）java.lang.OutOfMemoryError：heap space(比较常见)java.lang.OutOfMemoryError: PermGen space (经常出现)java.lang.OutOfMemoryError: GC overhead limit exceeded（某项操作使用大量内存时发生）现象2、通过loadrunner的windows监控图的部分指标走势能猜测是否发生内存泄漏。i、Private Bytes和Working Set持续走高 是指当前进程中运行的私有内存，如果此内存不断攀升，表示当前存在的内存泄漏，一般情况如果资源合理利用的话，该指标值波动比较平稳。ii、Available Bytes持续走低，单位是兆字节（参考值：=10%）。表明进程当前可使用的内存字节数。空闲内存过小可能是内存不足或内存泄漏引起，需要根据系统实际情况监控分析。现象3、通过jconsole监控JVM内存的”PS Old Gen”曲线持续上升，并且GC时间变得很漫长，表明存在内存泄漏问题，如图四、 分析导致内存泄漏的原因我们可以通过在tomcat启动文件中添加一些配置信息，使程序运行时只要发生内存溢出，就能自动导出发生问题时刻的dump（堆转储）文件，方便我们后面使用MAT工具诊断分析dump文件中的信息。下面开始具体步骤：名词解释：MAT工具：被认为是一个“傻瓜式“的堆转储文件分析工具，你只需要轻轻点击一下鼠标就可以生成一个专业的分析报告。即使新手也能一步到位Dump文件：JVM 能够记录下问题发生时系统的部分运行状态，并将其存储在堆转储 (Heap Dump) 文件中，从而为我们分析和诊断问题提供了重要的依据。1、首先登陆应用服务器，打开一个项目的tomcat文件夹bin目录下的启动文件catalina2、在-XX:MaxPermSize后面添加-XX:+HeapDumpOnOutOfMemoryError，图中是添加后的效果。添加此属性后，应用程序发生内存泄漏后，bin目录中就会生成一个.hprof后缀的dump文件PS：生成的dump文件非常大，通常几百兆到上GB。1、 在网上下载一个Memory Analyzer Tool工具，简称MAT。下载地址：/downloads/download.php?file=/mat/1.6/rcp/MemoryAnalyzer-0160531-win32.win32.x86_64.zip2、 安装完成之后，为了更有效率的使用 MAT，我们还需要做一些配置工作。因为通常而言，分析一个dump(堆转储)文件需要消耗很多的堆空间，为了保证分析的效率和性能，在有条件的情况下，我们会建议分配给 MAT 尽可能多的内存资源。你可以采用如下两种方式来分配内存更多的内存资源给 MAT。编辑文件 MemoryAnalyzer.ini，在里面修改该信息为2GB: vmargs Xmx2048m。至此，MAT 就已经成功地安装配置好了，开始进入实战吧。3、 File - Open Heap Dump,选择步骤3的dump文件PS：由于文件非常大，所以打开时间比较长，请耐心等待4、 dump文件打开后，选择第一项，点Finish5、 如图，加载完毕6、 万事俱备，接下来，我们就可以开始体验一键式的堆存储分析功能了。7、 分析三部曲一：内存消耗的整体状况从上图中我们可以看到可疑对象1（problem suspect 1）占消耗内存的20.8%，在图的下方还有对这个可疑对象的进一步描述。我们可以看到内存是由 org.springframework.beans.factory.support.DefaultListableBeanFactory的实例消耗的，org.springframework负责这个对象的加载。这段描述非常短，但我相信您已经可以从中找到很多线索了，比如是哪个类占用了绝大多数的内存，它属于哪个组件等等。接下来，我们应该进一步去分析问题，为什么一个 DefaultListableBeanFactory 会占据了系统 20.8% 的内存，谁阻止了垃圾回收机制对它的回收。8、 分析三部曲一：分析问题所在首先我们简单回顾下 JAVA 的内存回收机制，内存空间中垃圾回收的工作由垃圾回收器 (Garbage Collector,GC) 完成的，它的核心思想是：对虚拟机可用内存空间，即堆空间中的对象进行识别，如果对象正在被引用，那么称其为存活对象，反之，如果对象不再被引用，则为垃圾对象，可以回收其占据的空间，用于再分配。在垃圾回收机制中有一组元素被称为根元素集合，它们是一组被虚拟机直接引用的对象，比如，正在运行的线程对象，系统调用栈里面的对象以及被 system class loader 所加载的那些对象。堆空间中的每个对象都是由一个根元素为起点被层层调用的。因此，一个对象还被某一个存活的根元素所引用，就会被认为是存活对象，不能被回收，进行内存释放。因此，我们可以通过分析一个对象到根元素的引用路径来分析为什么该对象不能被顺利回收。如果说一个对象已经不被任何程序逻辑所需要但是还存在被根元素引用的情况，我们可以说这里存在内存泄露。现在，让我们开始真正的寻找内存泄露之旅，点击“Details ”链接，可以看到如图 8 所示对可疑对象 1 的详细分析报告。我们查看下从 GC 根元素到内存消耗聚集点的最短路径：我们可以很清楚的看到整个引用链，内存聚集点是一个拥有大量对象的集合，如果你对代码比较熟悉的话，相信这些信息应该能给你提供一些找到内存泄露的思路了。接下来，我们再继续看看，这个对象集合里到底存放了