OutOfMemoryError

OutOfMemoryError，Java堆溢出了，这表明程序有严重的问题。

我们需要找造成OutOfMemoryError原因。

一般有两种情况：

1、内存泄露，对象已经死了，无法通过垃圾收集器进行自动回收，通过找出泄露的代码位置和原因，才好确定解决方案；

2、内存溢出，内存中的对象都还必须存活着，这说明Java堆分配空间不足，检查堆设置大小（-Xmx与-Xms），检查代码是否存在对象生命周期太长、持有状态时间过长的情况。甚至优化代码减少临时变量的产生。

以上是处理Java堆问题的思路，具体是怎么进行分析，这里介绍的是使用Eclipse Memory Analyzer tool(MAT)工具分析的过程。

生成dump文件     

    通过jvm参数--XX:+HeapDumpOnOutOfMemoryError可以让JVM在出现内存溢出时候Dump出当前的内存转储快照。

    -XX:HeapDumpPath=${目录}参数表示生成DUMP文件的路径，如不设置，默认存储在jvm 运行环境目录。如我们这使用的是tomcat 默认dump文件存储在 tomcat/bin 目录下。也可以指定文件名称，如果不指定文件名，默认文件示例如 下：java_pid2821.hprof，其中2821为Java进程号。

上面的参数是设置内存溢出时，dump 转储出内存影像。也可以手工导出来随时分析。但各厂商的jvm 手工dump 方法有小区别，具体可以根据自己jvm 型号google。如 Oracle JVM的6.0版本去掉了-XX:+HeapDumpOnCtrlBreak参数（-XX:+HeapDumpOnCtrlBreak参数表示可以通过kill  -3  <pid>根据需要产生DUMP文件），如果需要产生DUMP文件，请采用jmap命令，命令行格式如下：

    jmap  -dump:format=b,file=managed1_heapdump.hprof  <pid>

其中managed1_heapdump.hprof表示生成的DUMP文件名称，pid表示Java进程号（win通过任务管理器查看tomcat的进程pid，linux用ps命令查看进程pid）。

内存dump文件格式：    .hprof  后缀文件,内存转储以后就是使用mat 进行分析了。

安装eclipse 和mat

eclispe install mat:

help install new software

eclipse softwar repository:

http://download.eclipse.org/mat/1.5/update-site/

切换到 Memory Analysis 模式

配置环境参数

安装完成后，为了更有效率的使用 MAT，我们可以配置一些环境参数。因为通常而言，分析一个堆转储文件需要消耗很多的堆空间，为了保证分析的效率和性能，在有条件的情况下，我们会建议分配给 MAT 尽可能多的内存资源。你可以采用如下两种方式来分配内存更多的内存资源给 MAT。

一种是修改启动参数 MemoryAnalyzer.exe-vmargs -Xmx4g

另一种是编辑文件 MemoryAnalyzer.ini，在里面添加类似信息 -vmargs– Xmx4g。

说明：

1. MemoryAnalyzer.ini中的参数一般默认为-vmargs– Xmx1024m，这就够用了。假如你机器的内存不大，改大该参数的值，会导致MemoryAnalyzer启动时，报错:Failed to create the Java Virtual Machine。

2.当你导出的dump文件的大小大于你配置的1024m（说明1中，提到的配置：-vmargs– Xmx1024m），MAT输出分析报告的时候，会报错：An internal error occurred during: "Parsing heap dump from XXX”。适当调大说明1中的参数即可。

可以参考官网给出的处理方式:

Alternatively, edit the MemoryAnalyzer.ini to contain:

-vmargs

-Xmx2g

-XX:-UseGCOverheadLimit

 

>>我的使用情况：

一个3.2G的dump文件，使用jvisualvm打开用了30分钟，且查看类的某实例时打开时间也很久。

使用MAT插件，总是报不能解析，调整xmx为1024M后仍不能，win7 32位分配内存太大会报不开。

使用RCP版，默认配置xmx=1024M也未能打开,调整成1300M后解析内存使用情况。？？？？

 

 

获取堆转储文件

只要你设置了如下所示的 JVM 参数：

-XX:+HeapDumpOnOutOfMemoryError

JVM 就会在发生内存泄露时抓拍下当时的内存状态，也就是我们想要的堆转储文件。

如果你不想等到发生崩溃性的错误时才获得堆转储文件，也可以通过设置如下 JVM 参数来按需获取堆转储文件。

-XX:+HeapDumpOnCtrlBreak

除此之外，还有很多的工具，例如 JMap，JConsole 都可以帮助我们得到一个堆转储文件。本文实例就是使用 JMap 直接获取了 Eclipse Galileo 进程的堆转储文件。您可以使用如下命令：

JMap -dump:format=b,file=<dumpfile> <pid>

不过，您需要了解到，不同厂家的 JVM 所生成的堆转储文件在数据存储格式以及数据存储内容上有很多区别， MAT 不是一个万能工具，它并不能处理所有类型的堆存储文件。但是比较主流的厂家和格式，例如 Sun, HP, SAP 所采用的 HPROF 二进制堆存储文件，以及 IBM 的 PHD 堆存储文件等都能被很好的解析（您需要安装额外的插件，请参考 相关说明，本文不作详细解释）。

万事俱备，接下来，我们就可以开始体验一键式的堆存储分析功能了。

第二部分 使用篇

首先，启动前面安装配置好的 Memory Analyzer tool , 然后选择菜单项 File- Open Heap Dump 来加载需要分析的堆转储文件。文件加载完成后，你可以看到如图 所示的界面：

可以看到 MAT工具提供了一个很贴心的功能，将报告的内容压缩打包到一个 zip文件，并把它存放到原始堆转储文件的存放目录下，这样如果您需要和同事一起分析这个内存问题的话，只需要把这个小小的 zip包发给他就可以了，不需要把整个堆文件发给他。并且整个报告是一个 HTML格式的文件，用浏览器就可以轻松打开。

使用MAT打开dump文件，等待一会后，会弹出向导界面，保持默认设置，直接点Finish即是分析内存泄露问题。在点击Finish后，会出现overview界面，您可以点击工具栏上的 Leak Suspects 菜单项来生成内存泄露分析报告，也可以直接点击饼图下方的 Reports->Leak Suspects链接来生成报告。如图：

MAT工具分析了heap dump后在界面上非常直观的展示了一个饼图，该图深色区域被怀疑有内存泄漏，可以发现整个heap才64M内存，深色区域就占了99.5%。接下来是一个简短的描述，告诉我们main线程占用了大量内存，并且明确指出system class loader加载的"java.lang.Thread"实例有内存聚集，并建议用关键字"java.lang.Thread"进行检查。所以，MAT通过简单的两句话就说明了问题所在，就算使用者没什么处理内存问题的经验。在下面还有一个"Details"链接，在点开之前不妨考虑一个问题：为何对象实例会聚集在内存中，为何存活（而未被GC）？是的——Strong Ref，那么再走近一些吧。如图：

点击了"Details"链接之后，除了在上一页看到的描述外，还有Shortest Paths To the Accumulation Point和Accumulated Objects部分，这里说明了从GC root到聚集点的最短路径，以及完整的reference chain。观察Accumulated Objects部分，java.util.HashMap和java.lang.Object[1000000]实例的retained heap(size)最大，在上一篇文章中我们知道retained heap代表从该类实例沿着reference chain往下所能收集到的其他类实例的shallow heap(size)总和，所以明显类实例都聚集在HashMap和Object数组中了。这里我们发现一个有趣的现象，既Object数组的shallow heap和retained heap竟然一样，通过Shallow and retained sizes一文可知，数组的shallow heap和一般对象（非数组）不同，依赖于数组的长度和里面的元素的类型，对数组求shallow heap，也就是求数组集合内所有对象的shallow heap之和。好，再来看org.rosenjiang.bo.Pilot对象实例的shallow heap为何是16，因为对象头是8字节，成员变量int是4字节、String引用是4字节，故总共16字节。

 

在Accumulated Objects视图中，retained heap占用最多的是hashMap和object数组，为啥它们会占用这么大的heap呢？这个时候需要分析hashMap和object数组中存放了一些什么对象？接着往下看，来到了Accumulated Objects by Class区域，顾名思义，这里能找到被聚集的对象实例的类名。org.rosenjiang.bo.Pilot类上头条了，被实例化了290,325次，再返回去看程序，我承认是故意这么干的。还有很多有用的报告可用来协助分析问题，只是本文中的例子太简单，也用不上。