基於JavaCore文件的深刻剖析

 發生時光

　　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文件，哪些對象占用了太多的客棧空間，來發明招致內存洩漏或許能夠惹起內存洩漏的對象。