前几天有现场报问题,客户端在持续运行一天后,再次点击就失去响应;
确定问题篇:
=====================================================
将截取 thread dump的方式告知现场同事后收到具体的thread dum日志,最后有如下一段:
Heap
def new generation total 106368K, used 106327K [0x03d20000, 0x0b080000, 0x0b080000)
eden space 94592K, 100% used [0x03d20000, 0x09980000, 0x09980000)
from space 11776K, 99% used [0x09980000, 0x0a4f5ef8, 0x0a500000)
to space 11776K, 0% used [0x0a500000, 0x0a500000, 0x0b080000)
tenured generation total 1417856K, used 1417855K [0x0b080000, 0x61920000, 0x61920000)
the space 1417856K, 99% used [0x0b080000, 0x6191fff8, 0x61920000, 0x61920000)
compacting perm gen total 65536K, used 45968K [0x61920000, 0x65920000, 0x69920000)
the space 65536K, 70% used [0x61920000, 0x64604298, 0x64604400, 0x65920000)
No shared spaces configured.
osgi> Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
就像我这样不明眼的人都能看出,内存泄漏了
现在对log,进行一下分析:
分析的依据,请见:
http://www.iteye.com/topic/212967 //里面还有对其他文章的引用
def new generation total 106368K, used 106327K //这个指的是年轻带内存区域,分配了106368K,
使用了106327K ;
eden space 94592K, 100% used //eden 用完
from space 11776K, 99% used //from Survivor区用完
to space 11776K, 0% //to Survivor 区因为垃圾回收机制的问题,只会是0%
//以上说明年轻区已经用完了
tenured generation total 1417856K, used 1417855K
the space 1417856K, 99% used //说明年老区内存已经用完,因为年老区一般存放生命周期比较长的对象,
所以,说明很有可能有大量的java对象被长时间的持有;
compacting perm gen total 65536K, used 45968K
the space 65536K, 70% used //持久区还有空间
以上的分析,应该就能的出,系统确实有内存泄露的问题!!!
分析问题篇:
=====================================================
基本确认了问题,现在要对问题进行分析了;使用jprofiler来对系统进行性能检测;
因为我们的客户端是基于RCP开发的,并打包成exe可执行的文件,而jprofiler运行的时候,需要指定
被监控类的主类,或是jar文件;呵呵,傻眼了
但是一想,java的程序万变不离其宗,即使是通过exe来启动的。google了一下,有文章上写
RCP启动不成功的,然后填出一堆的异常串,看看最底下的报错语句
at org.eclipse.equinox.launcher.Main.run(Main.java:1236)
就是这个类了,顺藤摸瓜,发现启动的架包就是org.eclipse.equinox.launcher_1.0.1.R33x_v20080118.jar,
哈哈,搞定!就这么一配,哈哈jprofiler带着系统一起运行起来了;
这一两天都在使用jprofiler分析......,因为有其他更重要的事,所以暂时耽搁下,以后再回来