当前位置: 移动技术网 > IT编程>开发语言>Java > 基于JavaCore文件的深入分析

基于JavaCore文件的深入分析

2019年07月22日  | 移动技术网IT编程  | 我要评论

 产生时间

  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文件,哪些对象占用了太多的堆栈空间,来发现导致内存泄露或者可能引起内存泄露的对象。

如对本文有疑问, 点击进行留言回复!!

相关文章:

验证码:
移动技术网