生成時間
Java プログラムの実行中に、JavaCore および HeapDump ファイルが生成されることがあります。これは通常、Java プログラムで致命的な問題が発生したときに発生します。
場合によっては、致命的な問題が発生した後でも、Java アプリケーションが停止せずに実行を継続できることがあります。
しかし、場合によっては致命的な問題が発生し、Java プロセスが停止してしまうことがあります。
致命的なエラーが発生する前に Java アプリケーションの実行状態を保持するために、JVM は停止する前に JavaCore ファイルと HeapDump ファイルという 2 つのファイルを生成します。
違いは何ですか
JavaCore は CPU に関するものですが、HeapDump ファイルはメモリに関するものです。
JavaCore ファイルは主に、ある時点での Java アプリケーションの各スレッドの実行位置、つまり、JVM がどのクラス、どのメソッド、どの行を実行したかを保存します。テキストファイルですので、開くと各スレッドの実行スタックがスタックトレースとして表示されます。 JavaCore ファイルを分析することで、アプリケーションが特定の時点で「スタック」しているかどうか、つまり、長時間応答を受け取らないデータベース クエリなど、特定の時点で実行に時間がかかりすぎるかどうかを知ることができます。最終的にはシステムのクラッシュにつながります。
HeapDump ファイルは、特定の時点での JVM ヒープ内のオブジェクトの使用状況を保存するバイナリー ファイルです。この種のファイルを分析するには、IBM Heap Analyzer などの対応するツールが必要です。このタイプのファイルの最も重要な機能は、システムでメモリ オーバーフローが発生しているかどうかを分析することです。
生成方法
これら 2 つのファイルは手動で生成できます。システムが遅くなったり応答しなくなったりする状況が発生した場合は、JavaCore ファイルと HeapDump ファイルを手動で生成できます。
Unix/Linux では、これら 2 つのファイルを生成する方法は次のとおりです。
# ps -ef | java
ユーザー 4616 4582 0 17:30 ポイント/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
# キル -3 5580
分析方法
JavaCoreファイル
2 つのファイル セットは、2 つのデータ セットの同じ位置で同じスレッドが実行されていることが判明した場合、2 つの時点でのスレッドの実行位置を確認できるため、JavaCore を分析する場合に特に効果的です。ある時点でプログラムが非常に高速に実行されるため、ここに問題がある可能性があります。これは、この 2 つのファイルを分析することで原因を特定し、解決できることを意味します。問題。
JavaCore ファイルのヘッダーには「現在のスレッドの詳細」マークがあり、JavaCore が生成されたときに実行されているシステムのスレッド ID を記録することで、ファイル内のスレッドの詳細情報を確認できます。スレッドが実行されているクラスと JavaCore の原因。
NULL -------------------------------------------------- -----------------------
0SECTION TITLE サブコンポーネント ダンプ ルーチン
NULL ===============================
1TISIGINFOOUTOFMEMORYを受信しました
1TIDATETIME 日付: 2011/12/07 15:59:42
1TIFILENAME Javacore ファイル名:/usr/WebSphere/AppServer/profiles/WCSProdNode2/javacore19202086.1323298782.txt
NULL -------------------------------------------------- -----------------------
0SECTION XHPI サブコンポーネント ダンプ ルーチン
NULL ==============================
1XHTIME 2011 年 12 月 7 日水曜日 15:59:42
1XHSIGRECV 予期しない信号 -1 を <unknown> の 0x0 で受信しました。処理は終了しました。
1XHFULLVERSION J2RE 1.4.2 IBM AIX ビルド ca142ifx-20090918 (SR13 FP2)
NULL
1XHCURRENTTHD 現在のスレッドの詳細
NULL ------------------------
2XHCURSYSTHD "Webコンテナ: 5" sys_thread_t:0x45FB5328
3XHNATIVESTACK ネイティブ スタック
NULL-----------
3XHSTACKLINEERR は使用できません - スタック アドレスが無効です
:::
:::
0SECTION XM サブコンポーネントダンプルーチン
NULL ============================
NULL
1XMCURTHDINFO 現在のスレッドの詳細
NULL ------------------------
3XMTHREADINFO "WebContainer : 5" (TID:0x70A8E260、sys_thread_t:0x45FB5328、状態:R、ネイティブ ID:0x5CC0) prio=5
org.apache.taglibs.standard.tag.common.core.ImportSupport$ImportResponseWrapper.getString の 4XESTACKTRACE (不明なソース)
org.apache.taglibs.standard.tag.common.core.ImportSupport.acquireString の 4XESTACKTRACE (不明なソース)
org.apache.taglibs.standard.tag.common.core.ImportSupport.doEndTag の 4XESTACKTRACE (ソース不明)
4XESTACKTRACE com.ibm._jsp._part._jspx_meth_c_import_3(_part.java(コンパイルされたコード))
4XESTACKTRACE com.ibm._jsp._part._jspx_meth_c_otherwise_3(_part.java(コンパイルされたコード))
4XESTACKTRACE com.ibm._jsp._part._jspx_meth_c_choose_4(_part.java(コンパイルされたコード))
4XESTACKTRACE com.ibm._jsp._part._jspService(_part.java:3237)
ヒープダンプファイル
HeapDump ファイルは、指定された時点での Java スタックのスナップショットであり、イメージ ファイルの一種です。ヒープ アナライザー ツールは、HeapDump ファイルを分析して、メモリ リークを引き起こすオブジェクト、またはメモリ リークを引き起こす可能性のあるオブジェクトを見つけるためにスタック領域を占有しすぎるオブジェクトを特定します。