In-depth analysis based on JavaCore files

Generation Time

When a Java program is running, Java core and HeapDump files are sometimes generated. This occurs when a Java program encounters a fatal problem.

Sometimes, when a fatal problem occurs, the Java application will not die and can continue to run;

But sometimes a fatal problem occurs, and the Java Process will die;

To retain the running status before a fatal error occurs to a Java application, JVM generates two files before it dies: JavaCore and HeapDump.

What is the difference?

　　JavaCore is about CPU, while HeapDump is about memory.

The JavaCore file mainly stores the running position of each Java application thread at a certain time point, that is, the class, method, and line to which the JVM executes. It is a text file. Once opened, the execution stack of each thread is displayed as a stack trace. By analyzing the JavaCore file, you can see if the application is stuck at a certain point, that is, the running time at a certain point is too long, such as database query, and the response is not received for a long time, the system crashes.

The HeapDump file is a binary file that stores the usage of objects in the JVM Heap at a certain time point. Such files need to be analyzed by appropriate tools, such as IBM Heap Analyzer. The most important role of such files is to analyze whether memory overflow exists in the system.

How to generate

These two files can be manually generated. When the system slows down or does not respond, the JavaCore and HeapDump files are generated manually.

　　On Unix/Linux, the method for generating these two files is as follows:

Copy codeThe Code is as follows:

# Ps-ef | grep java
User 4616 4582 0 00:00:00 pts/0 grep java
Root 5580 1 0 Oct27? 00:02:27/usr/bin/java-server-XX: PermSize = 64 M-XX: MaxPermSize = 128 m-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 the Java Process id, and then execute the 'Kill-3 process number' operation. After the file is generated, perform the same operation and generate a group of files.

How to analyze

　　JavaCore File

The two sets of files are particularly effective when analyzing JavaCore, because it can be seen that the thread is executed at two successive time points. If the same thread is executed at the same position in two sets of data, it indicates that there may be a problem here, because the program runs extremely fast. If both are at a certain point, it indicates that this time is very large. By analyzing these two files, locate the cause and solve the problem.

The header of the JavaCore file has a "Current Thread Details" mark, which records the Thread id of the system running when the JavaCore is generated. The Thread id is used to find detailed information about the Thread in the file, this information records the JavaCore generated when the thread runs a class.

Copy codeThe Code is as follows:

NULL ------------------------------------------------------------------------
0 section title subcomponent dump routine
NULL ======================================
1 TISIGINFOOUTOFMEMORY received
1 TIDATETIME Date: at 15:59:42
1 TIFILENAME Javacore filename:/usr/WebSphere/AppServer/profiles/WCSProdNode2/javacore192086.1323298782.txt
NULL ------------------------------------------------------------------------
0 section xhpi subcomponent dump routine
NULL ====================================
1 XHTIME Wed Dec 7 15:59:42 2011
1 XHSIGRECV Unexpected signal-1 received at 0x0 in <unknown>. Processing terminated.
1 XHFULLVERSION J2RE 1.4.2 ibm aix build ca142ifx-20090918 (SR13 FP2)
NULL
1 XHCURRENTTHD Current Thread Details
NULL ----------------------
2 XHCURRSYSTHD "WebContainer: 5" sys_thread_t: 0x45FB5328
3 XHNATIVESTACK Native Stack
NULL ------------
3 XHSTACKLINEERR unavailable-stack address not valid
:::
:::
0 section xm subcomponent dump routine
NULL ==================================
NULL
1 XMCURTHDINFO Current Thread Details
NULL ----------------------
3 XMTHREADINFO "WebContainer: 5" (TID: 0x70A8E260, sys_thread_t: 0x45FB5328, state: R, native ID: 0x5CC0) prio = 5
4 XESTACKTRACE at org. apache. taglibs. standard. tag. common. core. ImportSupport $ ImportResponseWrapper. getString (Unknown Source)
4 XESTACKTRACE at org. apache. taglibs. standard. tag. common. core. ImportSupport. acquireString (Unknown Source)
4 XESTACKTRACE at org. apache. taglibs. standard. tag. common. core. ImportSupport. doEndTag (Unknown Source)
4 XESTACKTRACE at com. ibm. _ jsp. _ part. _ jspx_meth_c_import_3 (_ part. java (Compiled Code ))
4 XESTACKTRACE at com. ibm. _ jsp. _ part. _ jspx_meth_c_otherwise_3 (_ part. java (Compiled Code ))
4 XESTACKTRACE at com. ibm. _ jsp. _ part. _ jspx_meth_c_choose_4 (_ part. java (Compiled Code ))
4 XESTACKTRACE at com. ibm. _ jsp. _ part. _ jspService (_ part. java: 3237)

In this way, you can find the cause of the problem by combining the current log file. However, this method can only find errors that are not caused by memory overflow. If there is a java/lang/outMemoryException error in the core File Header, you still do not know which class to execute.

　　HeapDump File
The HeapDump file is a Java stack snapshot at a specified time point and is an image file. By analyzing HeapDump files and which objects occupy too much stack space, Heap Analyzer can discover objects that may cause memory leakage or memory leakage.