Generationszeit
Wenn ein Java-Programm ausgeführt wird, werden manchmal JavaCore- und HeapDump-Dateien generiert. Dies tritt normalerweise auf, wenn das Java-Programm auf ein schwerwiegendes Problem stößt.
Manchmal stirbt die Java-Anwendung nach Auftreten eines schwerwiegenden Problems nicht ab und kann weiterhin ausgeführt werden.
Aber manchmal treten schwerwiegende Probleme auf und der Java-Prozess stürzt ab;
Um den Ausführungsstatus der Java-Anwendung beizubehalten, bevor ein schwerwiegender Fehler auftritt, generiert die JVM vor dem Abstürzen zwei Dateien, nämlich JavaCore- und HeapDump-Dateien.
Was ist der Unterschied
Bei JavaCore geht es um die CPU, während es bei HeapDump-Dateien um den Speicher geht.
Die JavaCore-Datei speichert hauptsächlich die Laufposition jedes Threads der Java-Anwendung zu einem bestimmten Zeitpunkt, dh welche Klasse, welche Methode und welche Zeile die JVM ausführt. Es handelt sich um eine Textdatei. Nach dem Öffnen können Sie den Ausführungsstapel jedes Threads sehen und als Stapelverfolgung anzeigen. Durch die Analyse der JavaCore-Datei können wir herausfinden, ob die Anwendung an einem bestimmten Punkt „hängen bleibt“, d Dies führte schließlich zu einem Systemabsturz.
Die HeapDump-Datei ist eine Binärdatei, die die Nutzung von Objekten im JVM-Heap zu einem bestimmten Zeitpunkt speichert. Für die Analyse dieser Art von Datei sind entsprechende Tools erforderlich, beispielsweise Tools wie IBM Heap Analyzer. Die wichtigste Funktion dieses Dateityps besteht darin, zu analysieren, ob im System ein Speicherüberlauf vorliegt.
So generieren Sie
Diese beiden Dateien können manuell generiert werden. Wenn das System langsam wird oder nicht mehr reagiert, können wir die JavaCore- und HeapDump-Dateien manuell generieren.
Unter Unix/Linux ist die Methode zum Generieren dieser beiden Dateien wie folgt:
# ps -ef |. grep java
Benutzer 4616 4582 0 17:30 pts/0 00:00:00 grep java
root 5580 1 0 Okt27 ? 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
# töten -3 5580
So analysieren Sie
JavaCore-Datei
Die beiden Dateisätze sind bei der Analyse von JavaCore besonders effektiv, da sie die Ausführungsposition des Threads zu zwei Zeitpunkten erkennen können Dies bedeutet, dass hier möglicherweise ein Problem vorliegt, da das Programm an einem bestimmten Punkt zweimal ausgeführt wird. Durch die Analyse dieser beiden Dateien können wir die Ursache herausfinden und beheben das Problem.
Im Header der JavaCore-Datei befindet sich eine Markierung „Aktuelle Thread-Details“, die die Thread-ID des Systems aufzeichnet, das beim Generieren von JavaCore ausgeführt wird. Verwenden Sie die Thread-ID, um die detaillierten Informationen des Threads in der Datei zu finden welche Klasse der Thread ausführt und JavaCore verursacht.
NULL ------------------------------------------------- - -----------------------
0SECTION TITLE Unterkomponenten-Dump-Routine
NULL ===============================
1TISIGINFOOUTOFMEMORY empfangen
1TIDATETIME Datum: 07.12.2011 um 15:59:42
1TIFILENAME Javacore-Dateiname:/usr/WebSphere/AppServer/profiles/WCSProdNode2/javacore19202086.1323298782.txt
NULL ------------------------------------------------- - -----------------------
0ABSCHNITT XHPI-Unterkomponenten-Dump-Routine
NULL ==============================
1XHTIME Mi 7. Dezember 15:59:42 2011
1XHSIGRECV Unerwartetes Signal -1 bei 0x0 in <unbekannt> empfangen. Verarbeitung beendet.
1XHFULLVERSION J2RE 1.4.2 IBM AIX Build ca142ifx-20090918 (SR13 FP2)
NULL
1XHCURRENTTHD Aktuelle Thread-Details
NULL -------------
2XHCURRSYSTHD „WebContainer: 5“ sys_thread_t:0x45FB5328
3XHNATIVESTACK Nativer Stack
NULL------------
3XHSTACKLINEERR nicht verfügbar – Stack-Adresse ungültig
:::
:::
0SECTION XM-Unterkomponenten-Dump-Routine
NULL ============================
NULL
1XMCURTHDINFO Aktuelle Thread-Details
NULL -------------
3XMTHREADINFO „WebContainer: 5“ (TID:0x70A8E260, sys_thread_t:0x45FB5328, state:R, native ID:0x5CC0) prio=5
4XESTACKTRACE unter org.apache.taglibs.standard.tag.common.core.ImportSupport$ImportResponseWrapper.getString (unbekannte Quelle)
4XESTACKTRACE unter org.apache.taglibs.standard.tag.common.core.ImportSupport.acquireString (unbekannte Quelle)
4XESTACKTRACE unter org.apache.taglibs.standard.tag.common.core.ImportSupport.doEndTag (unbekannte Quelle)
4XESTACKTRACE unter com.ibm._jsp._part._jspx_meth_c_import_3(_part.java(Compiled Code))
4XESTACKTRACE unter com.ibm._jsp._part._jspx_meth_c_otherwise_3(_part.java(Compiled Code))
4XESTACKTRACE unter com.ibm._jsp._part._jspx_meth_c_choose_4(_part.java(Compiled Code))
4XESTACKTRACE unter com.ibm._jsp._part._jspService(_part.java:3237)
HeapDump-Datei
Die HeapDump-Datei ist eine Momentaufnahme des Java-Stacks zu einem bestimmten Zeitpunkt und eine Art Bilddatei. Das Heap-Analysator-Tool analysiert die HeapDump-Datei, um herauszufinden, welche Objekte zu viel Stapelspeicher belegen, um Objekte zu finden, die Speicherverluste verursachen oder verursachen könnten.