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檔案，哪些物件佔用了太多的堆疊空間，來發現導致記憶體洩露或者可能引起記憶體洩露的物件。