Temps de génération
Lorsqu'un programme Java est en cours d'exécution, des fichiers JavaCore et HeapDump sont parfois générés. Cela se produit généralement lorsque le programme Java rencontre un problème fatal.
Parfois, après un problème fatal, l'application Java ne s'arrête pas et peut continuer à s'exécuter ;
Mais parfois, des problèmes fatals surviennent et le processus Java s'arrête ;
Afin de conserver l'état d'exécution de l'application Java avant qu'une erreur fatale ne se produise, la JVM génère deux fichiers avant de mourir, à savoir les fichiers JavaCore et HeapDump.
Quelle est la différence
JavaCore concerne le processeur, tandis que les fichiers HeapDump concernent la mémoire.
Le fichier JavaCore enregistre principalement la position d'exécution de chaque thread de l'application Java à un moment donné, c'est-à-dire quelle classe, quelle méthode et quelle ligne la JVM exécute. Il s'agit d'un fichier texte après l'avoir ouvert, vous pouvez voir la pile d'exécution de chaque thread et l'afficher sous forme de trace de pile. En analysant le fichier JavaCore, nous pouvons savoir si l'application est "bloquée" à un certain moment, c'est-à-dire si elle met trop de temps à s'exécuter à un certain moment, comme une requête de base de données qui ne reçoit pas de réponse pendant une longue période. temps, conduisant finalement à un crash du système.
Le fichier HeapDump est un fichier binaire qui enregistre l'utilisation des objets dans le tas JVM à un moment donné. Ce type de fichier nécessite des outils correspondants pour être analysé, tels que des outils tels qu'IBM Heap Analyzer. La fonction la plus importante de ce type de fichier est d'analyser s'il y a un débordement de mémoire dans le système.
Comment générer
Ces deux fichiers peuvent être générés manuellement. Lorsque nous rencontrons une situation où le système devient lent ou ne répond plus, nous pouvons générer les fichiers JavaCore et HeapDump manuellement.
Sous Unix/Linux, la méthode pour générer ces deux fichiers est la suivante :
#ps-ef |
utilisateur 4616 4582 0 17:30 pts/0 00:00:00 grep java
racine 5580 1 0 27 octobre ? 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 démarrer
# tuer -3 5580
Comment analyser
Fichier JavaCore
Les deux ensembles de fichiers sont particulièrement efficaces lors de l'analyse de JavaCore, car il peut voir la position d'exécution du thread à deux moments dans le temps. S'il s'avère que le même thread est exécuté à la même position dans les deux ensembles de données, il est possible de le faire. Cela signifie qu'il peut y avoir un problème ici, car le programme s'exécute extrêmement rapidement. S'il arrive deux fois à un certain point, cela signifie que ce point prend beaucoup de temps. En analysant ces deux fichiers, nous pouvons en découvrir la cause et le résoudre. le problème.
Il y a une marque « Détails du thread actuel » dans l'en-tête du fichier JavaCore, qui enregistre l'ID du thread du système en cours d'exécution lorsque JavaCore est généré. Utilisez l'ID du thread pour trouver les informations détaillées du thread dans le fichier. quelle classe le thread exécute et provoque JavaCore.
NUL ------------------------------------------------- - -----------------------
Routine de vidage du sous-composant 0SECTION TITLE
NULL ===============================
1TISIGINFOOUTOFMEMORY reçu
1TIDATETIME Date : 07/12/2011 à 15:59:42
1TIFILENAME Nom de fichier Javacore :/usr/WebSphere/AppServer/profiles/WCSProdNode2/javacore19202086.1323298782.txt
NUL ------------------------------------------------- - -----------------------
Routine de vidage du sous-composant XHPI 0SECTION
NULL ===============================
1XHTIME mer. 7 décembre 2011 15:59:42
1XHSIGRECV Signal inattendu -1 reçu à 0x0 dans <inconnu> Traitement terminé.
1XHFULLVERSION J2RE 1.4.2 IBM AIX build ca142ifx-20090918 (SR13 FP2)
NUL
1XHCURRENTTHD Détails du fil de discussion actuel
NUL ---------------------------
2XHCURRSYSTHD « WebContainer : 5 » sys_thread_t:0x45FB5328
Pile native 3XHNATIVESTACK
NUL------------
3XHSTACKLINEERR indisponible - adresse de pile non valide
:::
:::
Routine de vidage du sous-composant 0SECTION XM
NULL =============================
NUL
1XMCURTHDINFO Détails du fil de discussion actuel
NUL ---------------------------
3XMTHREADINFO "WebContainer : 5" (TID : 0x70A8E260, sys_thread_t : 0x45FB5328, état : R, ID natif : 0x5CC0) prio=5
4XESTACKTRACE sur org.apache.taglibs.standard.tag.common.core.ImportSupport$ImportResponseWrapper.getString (source inconnue)
4XESTACKTRACE sur org.apache.taglibs.standard.tag.common.core.ImportSupport.acquireString (source inconnue)
4XESTACKTRACE sur org.apache.taglibs.standard.tag.common.core.ImportSupport.doEndTag (source inconnue)
4XESTACKTRACE sur com.ibm._jsp._part._jspx_meth_c_import_3(_part.java(Code compilé))
4XESTACKTRACE sur com.ibm._jsp._part._jspx_meth_c_otherwise_3(_part.java(Code compilé))
4XESTACKTRACE sur com.ibm._jsp._part._jspx_meth_c_choose_4(_part.java(Code compilé))
4XESTACKTRACE sur com.ibm._jsp._part._jspService(_part.java:3237)
Fichier HeapDump
Le fichier HeapDump est un instantané de la pile Java à un moment spécifié et est une sorte de fichier image. L'outil Heap Analyzer analyse le fichier HeapDump pour découvrir quels objets occupent trop d'espace de pile afin de trouver les objets qui provoquent des fuites de mémoire ou peuvent provoquer des fuites de mémoire.