Performance analysis Tools-Eclipse Memory Analyzer tool (MAT) (ii) "Turn"

In this article, we will explain how mat analyzes the source of leaks based on Heapdump. Because the test example may be too simple to find a problem, I look forward to taking this extrapolate.

At first I had to say ClassLoader, in essence, it's work is to read the class file on the disk into memory, and then call the Java.lang.ClassLoader.defineClass method to tell the system to process the memory image into a valid bytecode. Java provides an abstract class ClassLoader, where all user-defined class loaders instantiate subclasses from ClassLoader. Systemclass Loader loads the user class by default without specifying a loader, sun.misc.launcher$appclassloader in Sun Java 1.5. For more details, please refer to the information below.

Prepare heap Dump
Take a look at the pilot class below, nothing special.

/**
* Pilot Class
* @author Rosen Jiang
*/
Package org.rosenjiang.bo;

public class pilot{

String name;
int age;

Public Pilot (String A, int b) {
name = A;
age = b;
}
}

Then look at the Oomheaptest class, it is how to bursting heapdump.

/**
* Oomheaptest Class
* @author Rosen Jiang
*/
Package org.rosenjiang.test;

Import Java.util.Date;
Import Java.util.HashMap;
Import Java.util.Map;
Import Org.rosenjiang.bo.Pilot;

public class Oomheaptest {
public static void Main (string[] args) {
Oom ();
}

private static void Oom () {
map<string, pilot> map = new hashmap<string, pilot> ();
object[] array = new object[1000000];
for (int i=0; i<1000000; i++) {
String d = new Date (). toString ();
Pilot P = new Pilot (d, I);
Map.put (i+ "Rosen Jiang", p);
Array[i]=p;
}
}
}

Yes, a lot of pilot class instances are constructed, and placed in arrays and maps. Because STRONGREF,GC naturally does not reclaim these objects, it is kept in the heap until it overflows. Before running, of course, you need to configure the VM parameter-xx:+heapdumponoutofmemoryerror in Eclipse. Okay, a moment. Memory overflow, the console typed the following information.

Java.lang.OutOfMemoryError:Java Heap Space
Dumping Heap to Java_pid3600.hprof
Heap dump file created [78233961 bytes in 1.995 secs]
Exception in thread "main" Java.lang.OutOfMemoryError:Java heap space

Java_pid3600.hprof is both heap dump and can be found under the project root directory where the Oomheaptest class resides.

Mat Installation

At the ends of the conversation, you have to install mat with heap dump.

MAT supports two types of installation, one is "standalone version", the user does not have to install the eclipseide environment, the mat is run as a standalone ECLIPSERCP application, and the other is "plugin version", which means that MAT can be used as a plugin for eclipseide. Integration with the Eclipse development platform.

Standalone version,: http://www.eclipse.org/mat/downloads.php

Download the zip package and unzip it to use. The download page is illustrated below:

Integrated with the Eclipse IDE installation process, see the following articles:

Http://www.ibm.com/developerworks/cn/opensource/os-cn-ecl-ma/index.html

After the installation is complete, we can configure some environment parameters for more efficient use of the MAT. Because in general, it takes a lot of heap space to analyze a heap dump file, and in order to ensure the efficiency and performance of the analysis, we recommend allocating to the MAT as much memory resources as possible in a conditional situation. There are two ways you can allocate memory for more memory resources to MAT.

One is to modify the startup parameters memoryanalyzer.exe-vmargs-xmx4g

The other is to edit the file Memoryanalyzer.ini, add similar information inside the-vmargs–xmx4g.

Description

1. The parameters in Memoryanalyzer.ini generally default to-vmargs–xmx1024m, which is sufficient. If your machine memory is not big, change the value of this parameter, will cause Memoryanalyzer start, error: Failed to create the Java Virtual machine.

2. When you export the size of the dump file larger than the 1024m you configured (description 1, the configuration mentioned in:-vmargs–xmx1024m), the Mat output analysis report, will error: An internal error occurred during: " Parsing heap dump from XXX ". Adjust the parameters in the description 1 appropriately.

At this point, the MAT has been successfully installed, the Open Heap dump button in the upper left corner of Eclipse, and the Java_pid3600.hprof file was found and opened according to the path just described.

First check out the series of files that the mat generates: (from another example)

You can see that the Mat tool provides a nice feature of compressing the contents of the report into a zip file and storing it in the repository of the original heap dump file, so if you need to analyze this memory problem with a colleague, just send the little zip package to him. There is no need to send the entire heap of files to him. And the entire report is an HTML-formatted file that can be easily opened with a browser.

Using the mat to open the dump file, wait for a while, will pop up the wizard interface, keep the default settings, directly point to finish is to analyze the memory leak problem. After clicking Finish, the Overview interface appears, you can click the Leak Suspects menu item on the toolbar to generate a memory leak analysis report, or you can directly click the Reports->leak Suspects link below the pie chart to generate the report.

The Mat tool analyzes the heap dump and visually displays a pie chart on the interface, where dark areas are suspected of memory leaks, and the entire heap is 64M of memory, with a dark area accounting for 99.5%. Here is a short description that tells us that the main thread is taking up a lot of memory and that the "Java.lang.Thread" instance loaded by the System class loader has a memory aggregation and recommends the keyword "Java.lang.Thread" For inspection. So, Mat explains the problem in two simple sentences, even if the user has no experience dealing with memory problems. There is also a "Details" link below, so consider a question before you open it: Why does an object instance accumulate in memory and why is it alive (not GC)? Yes--strong Ref, then come closer.


After clicking on the "Details" link, in addition to the description on the previous page, there is also the shortest Paths to the accumulation point and the accumulated Objects section, which illustrates the shortest path from GC root to aggregation points , as well as the complete reference chain. Observe the retained heap (size) of the accumulated Objects section, JAVA.UTIL.HASHMAP and java.lang.object[1000000] instances, in the previous article we know retained The heap represents the sum of the shallow heap (size) of other class instances that can be collected from the instance along reference chain, so that the obvious class instances are clustered in the HashMap and object arrays. Here we find an interesting phenomenon, both the shallow heap of the object array and the retained heap, and by shallow and retained sizes, the shallow heap of the array is different from the general object (not the array). Depending on the length of the array and the type of elements inside it, the shallow heap is evaluated on an array, that is, the sum of the shallow heap of all objects within the collection. Okay, look again. The shallow heap for the Org.rosenjiang.bo.Pilot object instance is 16, because the object header is 8 bytes, the member variable int is 4 bytes, the string reference is 4 bytes, and a total of 16 bytes.

In the accumulated objects view, the retained heap occupies most of the HashMap and object arrays, why do they occupy such a large heap? What objects are stored in the HashMap and object arrays at this time? Then look down and come to the accumulated Objects by class area, as the name implies, here to find the class name of the clustered object instance. Org.rosenjiang.bo.Pilot class headlines, was instantiated 290,325 times, and then returned to see the program, I admit it was deliberately done. There are a number of useful reports that can be used to assist in analyzing problems, but the examples in this article are too simple to use.

To learn more about the function of mat, give some examples (do not provide the corresponding code):

Example two:

When the heap dump problem is discovered through mat, you need to look for the code point that caused the memory leak. At this point, you often need to open the object dependency tree view, click the button.

You will see the following view:

The large right-hand side of the view can see the object's dependencies, and selecting an object will allow you to see some of the properties of the object in the small left window. If the value of the property is some memory address you can also click on the toolbar's Search button to search for specific object information. Mat is just the function of the tool that helps you with the analysis, and there are no fixed methods and guidelines for OOM problem analysis. Only use your keen insight, combine the source code, analyze the objects in memory to find bugs in the code.

Example three:

How to view the memory space occupied by an object
1. Open a new window as follows

2. Enter the class name (enter the full name of the class),

Resources:

Http://www.blogjava.net/rosen/archive/2010/06/13/323522.html

http://seanhe.iteye.com/blog/898277

Performance analysis Tools-Eclipse Memory Analyzer tool (MAT) (ii) "Turn"