In depth analysis based on JavaCore files
- 2020-04-01 01:56:31
- OfStack
Have the time
Java programs sometimes produce JavaCore and HeapDump files when they run, which typically occurs when a Java program encounters a fatal problem.
Sometimes a Java application can continue to run without dying after a fatal problem occurs.
But sometimes fatal problems occur and the Java process dies;
In order to preserve the running state of a Java application before a fatal error occurs, the JVM produces two files, JavaCore and HeapDump, before it dies.
What is the difference between
A JavaCore is about the CPU, and a HeapDump file is about memory.
The JavaCore file basically holds where each thread of the Java application is running at any given moment, which class, which method, and which line the JVM is executing on. It is a text file that, when opened, shows the execution stack for each thread as stack trace. By analyzing the JavaCore file, we can find out whether the application is "stuck" at a certain point, that is, it runs too long at a certain point, such as database query, long time no response, and finally cause the system to crash.
A HeapDump file is a binary file that stores the usage of objects in the JVM Heap at a given time and requires analysis by tools such as IBM Heap Analyzer. The most important role of such files is to analyze whether there is a memory leak in the system.
How to generate
These two files can be generated manually, and when the system is slow or unresponsive, the JavaCore and HeapDump files can be generated manually.
On Unix/Linux, the two files are generated 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
First, find out the Java process id, then perform the 'kill -3 process number' operation, and then do the same operation again after the file is generated to produce another set of files.
How to analyze
The JavaCore file
Two sets of documents in relation to the JavaCore particularly effective, because it can be seen in two time points, the position of thread execution, if it is found that has two sets of data in the same thread is executed in the same location, then may have a problem here, because the program is running very fast, if two are in one respect, illustrate this point are very time-consuming, and the analysis of the two files, find out the reason, then solve the problem.
There is a "Current Thread Details" tag in the header of the JavaCore file, which records the Thread id that the system runs when the JavaCore is generated. The Thread id is used to look up the Details of the Thread in the file, and the information records the JavaCore caused when the Thread runs which class.
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)
This can be combined with the log file at the time to find the cause of the problem. However, this method can only find is not out of memory error, in the core file header is Java/lang/outMemoryException errors still don't know which class is executed to come when you least expect them to.
Heapdumps file
A HeapDump file is a snapshot of the Java stack at a given moment, which is a mirror file. The Heap Analyzer tool finds objects that cause or may cause memory leaks by analyzing the HeapDump file to see which objects take up too much stack space.