tiempo de generacion
Cuando se ejecuta un programa Java, a veces se generan archivos JavaCore y HeapDump. Esto suele ocurrir cuando el programa Java encuentra un problema fatal.
A veces, después de que ocurre un problema fatal, la aplicación Java no muere y puede continuar ejecutándose;
Pero a veces ocurren problemas fatales y el proceso Java muere;
Para conservar el estado de ejecución de la aplicación Java antes de que ocurra un error fatal, la JVM genera dos archivos antes de morir, a saber, los archivos JavaCore y HeapDump.
cual es la diferencia
JavaCore se trata de CPU, mientras que los archivos HeapDump se tratan de memoria.
El archivo JavaCore guarda principalmente la posición de ejecución de cada subproceso de la aplicación Java en un momento determinado, es decir, qué clase, qué método y qué línea ejecuta la JVM. Es un archivo de texto. Después de abrirlo, puede ver la pila de ejecución de cada hilo y mostrarla como seguimiento de la pila. Al analizar el archivo JavaCore, podemos descubrir si la aplicación está "atascada" en un punto determinado, es decir, tarda demasiado en ejecutarse en un punto determinado, como una consulta de base de datos que no recibe una respuesta durante mucho tiempo. tiempo, lo que finalmente provocaría un fallo del sistema.
El archivo HeapDump es un archivo binario que guarda el uso de objetos en el montón de JVM en un momento determinado. Este tipo de archivo requiere las herramientas correspondientes para su análisis, como herramientas como IBM Heap Analyzer. La función más importante de este tipo de archivos es analizar si existe un desbordamiento de memoria en el sistema.
como generar
Estos dos archivos se pueden generar manualmente. Cuando nos encontramos con una situación en la que el sistema se vuelve lento o no responde, podemos generar los archivos JavaCore y HeapDump manualmente.
En Unix/Linux, el método para generar estos dos archivos es el siguiente:
#ps-ef |
usuario 4616 4582 0 17:30 pts/0 00:00:00 grep java
raíz 5580 1 0 27 de octubre? 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
# matar -3 5580
como analizar
Archivo JavaCore
Los dos conjuntos de archivos son particularmente efectivos al analizar JavaCore, porque puede ver la posición de ejecución del hilo en dos momentos en el tiempo. Si encuentra que el mismo hilo se ejecuta en la misma posición en los dos conjuntos de datos, significa que puede haber un problema aquí, porque el programa se ejecuta extremadamente rápido si está en un punto determinado dos veces, significa que este punto lleva mucho tiempo. Al analizar estos dos archivos, podemos encontrar la causa y resolverlo. el problema.
Hay una marca de "Detalles del subproceso actual" en el encabezado del archivo JavaCore, que registra la ID del subproceso del sistema que se ejecuta cuando se genera JavaCore. Utilice la ID del subproceso para encontrar la información detallada del subproceso en el archivo. qué clase está ejecutando el hilo y causa JavaCore.
NULO ------------------------------------------------- - -----------------------
0TÍTULO DE LA SECCIÓN rutina de volcado de subcomponentes
NULO =================================
1TISIGINFOOUTOFMEMORY recibido
1TIDATETIME Fecha: 2011/12/07 a las 15:59:42
1TIFILENAME Nombre de archivo Javacore:/usr/WebSphere/AppServer/profiles/WCSProdNode2/javacore19202086.1323298782.txt
NULO ------------------------------------------------- - -----------------------
0SECCIÓN Rutina de volcado de subcomponentes XHPI
NULO ================================
1XHTIME miércoles 7 de diciembre 15:59:42 2011
1XHSIGRECV Se recibió una señal inesperada -1 en 0x0 en <desconocido>. El procesamiento finalizó.
1XHFULLVERSION J2RE 1.4.2 IBM AIX compilación ca142ifx-20090918 (SR13 FP2)
NULO
1XHCURRENTTHD Detalles del hilo actual
NULO ---------------------------
2XHCURRSYSTHD "WebContainer: 5" sys_thread_t:0x45FB5328
Pila nativa 3XHNATIVESTACK
NULO------------
3XHSTACKLINEERR no disponible: dirección de pila no válida
:::
:::
0Rutina de volcado de subcomponentes SECTION XM
NULO =============================
NULO
1XMCURTHDINFO Detalles del hilo actual
NULO ---------------------------
3XMTHREADINFO "WebContainer: 5" (TID:0x70A8E260, sys_thread_t:0x45FB5328, estado:R, ID nativo:0x5CC0) prio=5
4XESTACKTRACE en org.apache.taglibs.standard.tag.common.core.ImportSupport$ImportResponseWrapper.getString (Fuente desconocida)
4XESTACKTRACE en org.apache.taglibs.standard.tag.common.core.ImportSupport.acquireString (Fuente desconocida)
4XESTACKTRACE en org.apache.taglibs.standard.tag.common.core.ImportSupport.doEndTag (Fuente desconocida)
4XESTACKTRACE en com.ibm._jsp._part._jspx_meth_c_import_3(_part.java(Código compilado))
4XESTACKTRACE en com.ibm._jsp._part._jspx_meth_c_otherwise_3(_part.java(Código compilado))
4XESTACKTRACE en com.ibm._jsp._part._jspx_meth_c_choose_4(_part.java(Código compilado))
4XESTACKTRACE en com.ibm._jsp._part._jspService(_part.java:3237)
Archivo de volcado de montón
El archivo HeapDump es una instantánea de la pila de Java en un momento específico y es una especie de archivo de imagen. La herramienta Heap Analyzer analiza el archivo HeapDump para descubrir qué objetos ocupan demasiado espacio de pila para encontrar objetos que causen pérdidas de memoria o que puedan causar pérdidas de memoria.