Generation time
When a Java program is running, JavaCore and HeapDump files are sometimes generated. This usually occurs when the Java program encounters a fatal problem.
Sometimes after a fatal problem occurs, the Java application will not die and can continue to run;
But sometimes fatal problems occur and the Java process will die;
In order to retain the running state of the Java application before a fatal error occurs, the JVM generates two files before dying, namely JavaCore and HeapDump files.
What's the difference
JavaCore is about CPU, while HeapDump files are about memory.
The JavaCore file mainly saves the running position of each thread of the Java application at a certain moment, that is, which class, which method, and which line the JVM executes. It is a text file. After opening it, you can see the execution stack of each thread and display it as stack trace. By analyzing the JavaCore file, we can find out whether the application is "stuck" at a certain point, that is, it takes too long to run at a certain point, such as a database query that does not receive a response for a long time, eventually leading to a system crash.
The HeapDump file is a binary file that saves the usage of objects in the JVM heap at a certain time. This kind of file requires corresponding tools to analyze, such as tools such as IBM Heap Analyzer. The most important function of this type of file is to analyze whether there is a memory overflow in the system.
How to generate
These two files can be generated manually. When we encounter a situation where the system becomes slow or unresponsive, we can generate the JavaCore and HeapDump files manually.
On Unix/Linux, the method to generate these two files is as follows:
# 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
How to analyze
JavaCore file
The two sets of files are particularly effective when analyzing JavaCore, because it can see the execution position of the thread at two points in time. If it is found that the same thread is executed at the same position in the two sets of data, it means there may be a problem here. , because the program runs extremely fast. If it is at a certain point twice, it means that this point is very time-consuming. By analyzing these two files, we can find out the cause and solve the problem.
There is a "Current Thread Details" mark in the header of the JavaCore file, which records the thread ID of the system running when JavaCore is generated. Use the thread ID to find the detailed information of the thread in the file. This information records which class the thread is running and causes 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)
HeapDump file
The HeapDump file is a snapshot of the Java stack at a specified time and is a kind of image file. The Heap Analyzer tool analyzes the HeapDump file to find out which objects occupy too much stack space to find objects that cause memory leaks or may cause memory leaks.