JavaCore资料分析和HeapDump文件分析

JavaCore文件分析和HeapDump文件分析

? ? ?最近被java内存溢出搞的烦躁不堪,所以专门抽空研究了一下JavaCore/HeapDump文件及其分析方法

?

文件产生的时间

Java程序运行时，有时会产生JavaCore及HeapDump文件，它一般发生于Java程序遇到致命问题的情况下。有时致命问题发生后，Java应用不会死掉，还能继续运行；但有时致命问题发生，Java进程会死掉；为了能够保留Java应用发生致命错误前的运行状态，JVM在死掉前产生两个文件，分别为JavaCore及HeapDump文件。

有何区别JavaCore是关于CPU的，而HeapDump文件是关于内存的。JavaCore文件主要保存的是Java应用各线程在某一时刻的运行的位置，即JVM执行到哪一个类、哪一个方法、哪一个行上。它是一个文本文件，打开后可以看到每一个线程的执行栈，以stack?? trace的显示。通过对JavaCore文件的分析可以得到应用是否“卡”在某一点上，即在某一点运行的时间太长，例如数据库查询，长期得不到响应，最终导致系统崩溃等情况。HeapDump文件是一个二进制文件，它保存了某一时刻JVM堆中对象使用情况，这种文件需要相应的工具进行分析，如IBM?? Heap Analyzer这类工具。这类文件最重要的作用就是分析系统中是否存在内存溢出的情况。

文件时如何生成这两个文件可以用手工的方式生成，当我们会遇到系统变慢或无响应的情况，这时就以采用手工的方式生成JavaCore及HeapDump文件。在Unix/Linux上，产生这两个文件的方法如下：

# ps -ef | grep java?
user?4616?4582?0?17:30?pts/0?00:00:00 grep java
root?5580?1?0?Oct27???00:02:27?/usr/bin/java?-server?-XX:PermSize=64M?-XX:MaxPermSize=128m-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager?-Djava.util.logging.config.file=/usr/local/tomcat8090/conf/logging.properties-Djava.endorsed.dirs=/usr/local/tomcat8090/endorsed?-classpath?:/usr/local/tomcat8090/bin/bootstrap.jar?-Dcatalina.base=/usr/local/tomcat8090-Dcatalina.home=/usr/local/tomcat8090?-Djava.io.tmpdir=/usr/local/tomcat8090/temp?? org.apache.catalina.startup.Bootstrap start# kill -3 5580

首先，找出Java进程id ，然后再执行‘kill -3 进程号’的操作，等文件生成后再做一次同样的操作，再产生一组文件。

如何分析

JavaCore文件两组文件在分析JavaCore时特别有效，因为它可以看出在先后两个时间点上，线程执行的位置，如果发现先后两组数据中同一线程都执行在同一位置，则说明此处可能有问题，因为程序运行是极快的，如果两次均在某一点上，说明这一点耗时是很大的，通过对这两个文件进行分析，查出原因，进而解决问题。JavaCore文件的头部有一个“Current Thread Details”标记，它记录了JavaCore产生时系统运行的线程id，使用线程id在文件中查找线程的详细信息，该信息中记载了线程运行哪个类的时候造成的JavaCore。

NULL?------------------------------------------------------------------------?
0SECTION TITLE?? subcomponent dump routine
NULL?===============================
1TISIGINFOOUTOFMEMORY received?
1TIDATETIME?Date:?2011/12/07?at?15:59:42
1TIFILENAME?Javacore filename:/usr/WebSphere/AppServer/profiles/WCSProdNode2/javacore19202086.1323298782.txt
NULL?------------------------------------------------------------------------
0SECTION XHPI subcomponent dump routine
NULL???==============================
1XHTIME?Wed Dec?7?15:59:42?2011
1XHSIGRECV?Unexpected?? signal?-1?received at?? 0x0?in?<unknown>. Processing?? terminated.
1XHFULLVERSION?J2RE?1.4.2?IBM AIX build ca142ifx-20090918?(SR13?? FP2)
NULL???????????
1XHCURRENTTHD?Current Thread?? Details
NULL?----------------------
2XHCURRSYSTHD?"WebContainer :?? 5"?sys_thread_t:0x45FB5328
3XHNATIVESTACK?Native Stack
NULL?------------
3XHSTACKLINEERR?unavailable?-?? stack address?not?valid
:::
:::
0SECTION XM subcomponent?? dump routine?
NULL?============================
NULL????????????
1XMCURTHDINFO?Current Thread Details
NULL?----------------------
3XMTHREADINFO?"WebContainer : 5"?(TID:0x70A8E260, sys_thread_t:0x45FB5328, state:R, native ID:0x5CC0)?? prio=5
4XESTACKTRACE?at?? org.apache.taglibs.standard.tag.common.core.ImportSupport$ImportResponseWrapper.getString(Unknown?? Source)
4XESTACKTRACE?at?? org.apache.taglibs.standard.tag.common.core.ImportSupport.acquireString(Unknown?? Source)
4XESTACKTRACE?at?? org.apache.taglibs.standard.tag.common.core.ImportSupport.doEndTag(Unknown?? Source)
4XESTACKTRACE?at?? com.ibm._jsp._part._jspx_meth_c_import_3(_part.java(Compiled Code))
4XESTACKTRACE?at?? com.ibm._jsp._part._jspx_meth_c_otherwise_3(_part.java(Compiled?? Code))
4XESTACKTRACE?at?? com.ibm._jsp._part._jspx_meth_c_choose_4(_part.java(Compiled Code))
4XESTACKTRACE?at?? com.ibm._jsp._part._jspService(_part.java:3237)

这样结合当时的日志文件可以找到问题产生的原因。不过，这种方法只能找到不是内存溢出的错误，对于在core文件头就有java/lang/outMemoryException的错误还是不知道是执行到哪个类的时候出现。

HeapDump文件HeapDump文件是指定时刻的Java堆栈的快照，是一种镜像文件。Heap Analyzer工具通过分析HeapDump文件，哪些对象占用了太多的堆栈空间，来发现导致内存泄露或者可能引起内存泄露的对象。

查看更多 下一篇