Shulou(Shulou.com)06/02 Report--

Today, I will talk to you about JavaCore/HeapDump files and their analysis methods, which may not be well understood by many people. in order to make you understand better, the editor has summarized the following contents for you. I hope you can get something according to this article.

Generation time

JavaCore and HeapDump files are sometimes generated when the Java program is running, which usually occurs when the Java program encounters fatal problems.

Sometimes after a fatal problem occurs, the Java application does not die and can continue to run.

But sometimes fatal problems occur, and the Java process dies.

In order to retain the running state of the Java application before a fatal error occurred, JVM produced two files, JavaCore and HeapDump, before he died.

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 time, that is, which class, which method and which line the JVM executes. It is a text file, and after opening it, you can see the execution stack of each thread, which is displayed by stack trace. Through the analysis of 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 database query, which does not get a response for a long time, resulting in system crash and so on.

The HeapDump file is a binary file that holds the usage of objects in the JVM heap at some point. This kind of file needs to be analyzed by tools such as IBM Heap Analyzer. The most important function of such files 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 in which the system becomes slow or unresponsive, we generate 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 10 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, and then execute the operation of 'kill-3 process number'. After the file is generated, do the same operation again, and then generate a set of files.

How to analyze

JavaCore file

The two groups of files are particularly effective in analyzing JavaCore, because it can see where the thread executes at two time points successively. If it is found that the same thread in two sets of data is executed in the same location, then there may be a problem here, because the program runs very fast. If both files are at a certain point, it is very time-consuming. Through the analysis of these two files, find out the reason. And then solve the problem.

The header of the JavaCore file has a "Current Thread Details" tag, which records the thread id running by the system when the JavaCore is generated, and uses the thread id to find the details of the thread in the file, which records the JavaCore caused by which class the thread is running.

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. 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)

In this way, combined with the log files at that time, we can find the cause of the problem. However, this method can only find errors that are not memory overflows, when there is a java/lang/outMemoryException error in the core header or when you don't know which class to execute to.

HeapDump file

The HeapDump file is a snapshot of the Java stack at a specified time and is a mirror file. The Heap Analyzer tool analyzes the HeapDump file to find out which objects take up too much stack space to find objects that cause or may cause memory leaks.

After reading the above, do you have any further understanding of the JavaCore/HeapDump file and its analysis methods? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.