JAVA OutOfMemoryError对应笔记,暨Eclipse memory analyzer(MAT)使用

最近一个项目,现场出了一个状况,不知什么原因发生了OutOfMemoryError。这个项目已经很有历史,数十万行代码,加上经手人不计其数,突然遇到OOM,现场折腾了很久,最后搞到我这边来。

因为我不在现场,远程对应,我也很晕,一路加内存(-xmx之类),强制资源回收System.gc之类,拿到现场,跑了几天还是OOM。没办法只能VM Dump分析了。不过过程虽有反复,但是通过使用EMA,没想到超过预期的顺利,很方便的就定位了问题,所以记录一下。

过程

1,其实JDK的Bin里面已经有了几个VM监视程序,像jmc.exe,jvisualvm.exe还是图形界面的,各种对象的内存占用情况可以输出。

比如 VisualVM,工具可以很方便的获得各个对象的内存占用情况,但是由于项目比较大,而且我们有文件缓存处理,最初data[]对象占用个500M内存,谁都没有太注意。

2,但是后来使用MAT一看,立即发现了这个data[]有问题。并不是我们缓存处理的内容,而是数据库链接没有正常关闭的问题。代码BUG

通过这个工具的提示,发现在运行一段时间后,内存中居然驻留了1万多个JDBC4PreStatemant实例,我去。。。。多少年了这个项目怎么活到现在的。。。

Detail点进去,定位到类

看了DBAccess这个方法,年代久远,都不知道谁写的,共通static(CRUD)方法里面新建了链接,却没有关闭(原本是出于性能的考虑)。分析原因:其实这个类本身没有问题,最早使用这个类的人,在使用完成之后,手动回收了链接资源,但是随着不停的维护,后来的担当变更了,没有仔细看这个类的目的,到处随便使用,导致最后在别的有些地方频繁调用时出现问题。查看了所有调用的地方,一一确认,并在合适的地方回收链接资源,现在空置时的内存消耗只有5-10M。。。

最后不禁感慨,没这个工具,要定位到那问题,不知道要费多大功夫。

当然,最后这个工具也会提示其他问题,比如一个变量占用太多内存,太多的同一实例等等,这个就要靠经验判断了,哪些是正常的,哪些则不然。

最后:

这个工具的下载方法:http://www.eclipse.org/mat/

补充:

1,可以通过JAVA 运行时添加 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=E:\Java\dump 参数来获得OOM发生时候的DUMP文件

2,或者JavaVisualVM的菜单,Application>heapdump来获得内存Dump