JAVA内存泄露、溢出的检查方法、工具介绍

问题发现：

在我们运行的一个项目上线运营后发现运行两天左右就会报内存溢出，只有重启tomcat才能恢复服务，异常信息如下：

java.lang.OutOfMemoryError: GC overhead limit exceeded

java.lang.OutOfMemoryError: Java heap space

原因分析：

在此之前必须先介绍一下关于jvm的内存控制，JVM即java虚拟机，它运行时候占用一定的内存，其大小是有限定的，如果程序在运行时jvm占用的内存大于某个限度，则会产生内存溢出，也就是“java.lang.outofmemoryerror”。如果jvm内存的没有限度，并且有无限大的内存，那jvm就永远不会出现内存溢出了。很明显无限的内存是不现实的，但是一般情况下我们程序运行过程所需要的内存应该是一个基础固定的值，如果仅是因为我们的项目所需内存超过了jvm设置内存值导致内存溢出，那么我们可以通过增大jvm的参数设置来解决内存溢出的问题。详细处理可参考java jvm的如下参数设置：-Xms -Xmx -Xmn -Xss

-Xms: 设置JVM初始内存，此值可以设置与-Xmx相同,以避免每次垃圾回收完成后JVM重新分配内存。

-Xmx:设置JVM最大可用内存。

-Xmn:设置年轻代大小，整个堆大小=年轻代大小+年老代大小+持久代大小.持久代一般固定大小为64m,所以增大年轻代后,将会减小年老代大小.此值对系统性能影响较大,Sun官方推荐配置为整个堆的3/8.

-Xss:设置每个线程的堆栈大小.在相同物理内存下,减小这个值能生成更多的线程.但是操作系统对一个进程内的线程数还是有限制的,不能无限生成。

在jvm参数调试过程中，发现分配最大内存数超过1G后，仍然会产生内存溢出的现象，而估计其正常分配使用的内存应该不会超过1G，那么由此可以基本断定其存在内存泄露现象，也就是一些原来分配的不再使用的内存不能被java的垃圾回归所回收，导致不断占用原分配的内存而不释放，导致不断申请更多的内存直到超过内存设置而导致内存溢出。

内存泄露的基本原理：

　　在C++语言程序中，使用new操作符创建的对象，在使用完毕后应该通过delete操作符显示地释放，否则，这些对象将占用堆空间，永远没有办法得到回收，从而引起内存空间的泄漏。如下的简单代码就可以引起内存的泄漏:

void function(){
　Int[] vec = new int[5];
}

 

在function()方法执行完毕后，vec数组已经是不可达对象，在C++语言中，这样的对象永远也得不到释放，称这种现象为内存泄漏。

　　而Java是通过垃圾收集器(Garbage Collection，GC)自动管理内存的回收，程序员不需要通过调用函数来释放内存，但它只能回收无用并且不再被其它对象引用的那些对象所占用的空间。在下面的代码中，循环申请Object对象，并将所申请的对象放入一个Vector中，如果仅仅释放对象本身，但是因为Vector仍然引用该对象，所以这个对象对GC来说是不可回收的。因此，如果对象加入到Vector后，还必须从Vector中删除，最简单的方法就是将Vector对象设置为null。

Vector v = new Vector(10);

for (int i = 1; i < 100; i++){

Object o = new Object();

　v.add(o);

　o = null;

}//此时，所有的Object对象都没有被释放，因为变量v引用这些对象。

　　实际上无用，而还被引用的对象，GC就无能为力了(事实上GC认为它还有用)，这一点是导致内存泄漏最重要的原因。

    而我们的项目可能是存在着内存泄露问题而导致内存溢出。

解决过程：

如何查找引起内存泄漏的原因呢?一般有两种思路:第一种，安排有经验的编程人员对代码进行走查和分析，找出内存泄漏发生的位置;第二种，就是利用一些内存检查分析工具来分析，找出内存泄露的具体位置可以快速解决。

软件测试的理论告诉我们，系统中永远存在一些没有暴露出来的问题，而且，系统的稳定性问题也不仅仅只是内存泄漏的问题，代码走查是提高系统的整体代码质量乃至解决潜在问题的有效手段。但在此仅总结一下本次问题解决所应用的有关内存检查和分析命令以及工具的相关介绍。

    第一阶段 通过jdk的GC输出进行测试

可以在 JAVA_OPTS增加以下参数打开jdk的GC输出日志：

-verbose:gc -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError

打开输出日志，jdk会在每一次的垃圾回收时打印相关日志，参考格式如下：

[GC [<collector>: <starting occupancy1> -> <ending occupancy1>, <pause time1> secs] <starting occupancy3> -> <ending occupancy3>, <pause time3> secs]

<collector>GC收集器的名称

<starting occupancy1> 新生代在GC前占用的内存

<ending occupancy1> 新生代在GC后占用的内存

<pause time1> 新生代局部收集时jvm暂停处理的时间

<starting occupancy3> JVM Heap 在GC前占用的内存

<ending occupancy3> JVM Heap 在GC后占用的内存

<pause time3> GC过程中jvm暂停处理的总时间

 

例：[GC [PSYoungGen: 131072K->10667K(152896K)] 137699K->17295K(1551040K), 0.0210980 secs] [Times: user=0.06 sys=0.01, real=0.02 secs]

注意短时间内关注GC的内存回收日志是没有什么作用的，重点需要关注的是Full级别的新生代和年老代的内存情况。

如下表中，发现年老代内存是不断增长的，基本可以确定是年老代内存泄露，有许多长时间未使用的分配内存得不到回收。

 

[PSYoungGen: 6735K->0K(152896K)] [PSOldGen: 000000K->6627K(1398144K)] 6735K->6627K(1551040K) [PSPermGen: 17676K->17676K(262144K)], 0.1521720 secs] [Times: user=0.15 sys=0.01, real=0.16 secs]

[PSYoungGen: 4754K->0K(153600K)] [PSOldGen: 201914K->86024K(1398144K)] 206668K->86024K(1551744K) [PSPermGen: 33065K->33065K(262144K)], 0.5517640 secs] [Times: user=0.56 sys=0.00, real=0.55 secs]

[PSYoungGen: 5495K->0K(164096K)] [PSOldGen: 166076K->99609K(1398144K)] 171571K->99609K(1562240K) [PSPermGen: 33680K->33680K(262144K)], 0.5221250 secs] [Times: user=0.52 sys=0.00, real=0.52 secs]

[PSYoungGen: 2584K->0K(164736K)] [PSOldGen: 194684K->76213K(1398144K)] 197268K->76213K(1562880K) [PSPermGen: 34027K->33173K(262144K)], 0.6575180 secs] [Times: user=0.66 sys=0.00, real=0.66 secs]

[PSYoungGen: 928K->0K(161728K)] [PSOldGen: 144867K->100205K(1398144K)] 145795K->100205K(1559872K) [PSPermGen: 34264K->34264K(262144K)], 0.5328980 secs] [Times: user=0.53 sys=0.00, real=0.53 secs]

[PSYoungGen: 1656K->0K(161984K)] [PSOldGen: 100205K->100602K(1398144K)] 101861K->100602K(1560128K) [PSPermGen: 34317K->34317K(262144K)], 0.4965370 secs] [Times: user=0.50 sys=0.00, real=0.50 secs]

泄露的结果是确定的，但是内存泄露点到底在哪根据日志也无法确切的查看清楚，通过在测试机器上的测试也很难找到哪块的业务操作才引起内存的增长。结果未能解决内存泄露问题。

第二阶段 通过jmap命令

jmap命令可以获得运行中的jvm的堆的快照，从而可以离线分析堆，以检查内存泄漏，检查一些严重影响性能的大对象的创建，检查系统中什么对象最多，各种对象所占内存的大小等等

命令格式

jmap [options] pid -dump:[live,]format=b,file=<filename>

-dump堆到文件,live指明是活着的对象,file指定文件名,pid 是java进程id

通过这个命令可以查看系统内存情况，但受限于所展示的内存通过能够保存到几十兆以上的的文件内容，手工分析查看实在是太过辛苦，所以也未能解决。

第三阶段 通过Eclipse Memory Analyzer 分析工具来分析

Eclipse Memory Analyzer是一种快速的,功能丰富的Java堆分析工具，以下简称MAT,可以帮助查找内存泄露,并减少内存消耗。 这个工具可以对由堆转储产生的数以亿计的对象进行分析,一旦堆转储被解析,可以在打开他的一瞬间,立即得到保留大小的单一对象,提取记录详细的信息，查看为什么这些对象对象资料没有被释放掉。使用这些功能的报告,可以对这些对象进行跟踪，找到内存泄露嫌疑人，也可以得到系统的性能指数,帮助优化系统。下面就来介绍一下如何使用该工具进行分析。

前面我们已经介绍了，可以通过jmap命令获得运行中的jvm的堆快照，那么想利于该工具进行分析第一步仍然是获得堆转储文件。具体命令如下：

jmap -dump:format=b,file=jmap.hprof 32460

注意，32460为java进程pid值，另外本分析工具支持的文件扩展名为hprof，所以将输出文件名定为hprof，有了这个文件我们就可以通过本工具来分析他。

启动Eclipse Memory Analyzer,是不是和eclipse开发平台非常类似？其实他还可做为eclipse的插件进行集成，在这就不详细介绍了，有兴趣的可以自己研究一下。

 

选择菜单File-Open HeadDump然后选择我们生成的堆转储文件

 

打开后他提示是否自动生成泄露检测报告，我们选择后，点finish完成

 

通过图中，MAT给出了关于本次检测有两处占用内存较多的疑似泄露，下面是详细说明

 

先从26%的嫌疑人suspect2看起，报告很直观的给出系统中有13个关于数据库链接的引用对象占用了59.83%的内存资源，我们还可以点击details查看一下详细情况。

 

可以看到这13个数据库链接引用其实就是数据库链接池的数据库链接对象。而数据库链接对象本身仅占用100K左右内存，因此不可能达到26M的内存占用量，所以基本可以断定是数据库链接占用了原查询过程中的一些结果集等对象的引用，造成内存泄露问题。

分析数据库链接池对象的相关代码，未发现数据库链接对象对其它对象的引用占用情况，后来通过一篇文档资料中介绍如下：

在MySQL jdbc 5.1.6里，默认情况下，如果一个Connection永远不掉用close，即使你每一个Statement, ResultSet都调用了close，仍然会有内存泄漏，换句话说，Statement的close没有把自己的资源释放干净，Statement会在对应的Connection里有缓存

在我们的项目中采用了数据库链接池的技术，我们的数据库链接应用完成后不是马上调用close方法关闭掉，而是返回给了数据库链接池管理。所以链接池中的活动connettion对象中实际上持有了Statement的引用，造成内存泄露。

解决此问题方法就是对connetion对象进行声明，不对statement对象做缓存，具体代码如下：

java.sql.Connection conn = DriverManager.getConnection(strConnString);

//下面这句很重要，具体作用就是让Statement每次close的时候通知Connection把缓存的Statement对象释放掉，这样就释放干净了

com.mysql.jdbc.Connection connMysql = (com.mysql.jdbc.Connection)conn;//强制转换

connMysql.setDontTrackOpenResources(true);//这个接口是mysql特有的public函数

最终泄露的主要问题解决，另外补充一点一些轻量级别的泄露是需要长期的积累等其占用较大的资源的时候才能体现出来，所以监测与检测需要时间慢慢积累逐步解决。