Eclipse Memory Analyzer tips for using

Eclipse memory Analyze is a Java heap dump file analysis tool that can help you to identify and reduce memory vulnerabilities.

Overview

For large JAVA applications, fine testing is also hard to block all vulnerabilities, even though we have done a lot of good work during the testing phase, many problems are exposed in the production environment and are difficult to reproduce in a test environment. The JVM is able to record some of the operational state of the system when the problem occurs and store it in a heap dump file, providing an important basis for us to analyze and diagnose the problem.

Often memory leak analysis is considered a difficult task, typically performed by a team of experienced people. However, today we are going to introduce the MAT (Eclipse Memory Analyzer) is considered to be a "fool-like" Heap Dump file analysis tool, you only need a click of the mouse to generate a professional analysis report. Compared to other memory leak analysis tools, MAT is very easy to use, basic can achieve a key in place, even the novice can quickly get started.

The mat is so easy to use, and you are interested to feel it yourself, so the first step is to install the mat.

Installation

There are 2 main ways of installation: Eclipse plugin and software version.

1, the Eclipse plug-in installation is very simple, click on the help---install new software------Add and then added the address, the path is: http://download.eclipse.org/mat/1.3/ update-site/Then

2, the software version of the installation path is: http://www.eclipse.org/mat/downloads.php, download windows.

Configuring Environment parameters

After the installation is complete, we also need to do some configuration work in order to use the MAT more efficiently. 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.

At this point, the MAT has been successfully installed in the configuration, and began to enter the actual combat it.

Write the memory overflow program as follows:

Program 1:

public class Heapoom {static class oomobject{}public static void Main (string[] args) {list<oomobject> list=new Array List<oomobject> (); while (true) List.add (new Oomobject ());}}

Program 2:

Listing 1. Memory leak code Snippet while (1<2) {person person  = new Person ("name", "Address", I);  V.add (person);  person = null;  }

Get heap dump File

Paddle, we first need to get a heap dump file. For convenience, this article uses the Sun JDK 6. Typically, as long as you set the JVM parameters as shown below:

-xx:+heapdumponoutofmemoryerror

The JVM captures the memory state at the time when a memory leak occurs, which is the heap dump file we want.

If you don't want to wait for a crash error to get a heap dump file, you can also get the heap dump file on demand by setting the following JVM parameter.

-xx:+heapdumponctrlbreak

In addition, there are a lot of tools, such as Jmap,jconsole, that can help us get a heap dump file. The example in this article is a heap dump file that uses JMap to get the Eclipse Galileo process directly. You can use the following command:

Jmap-dump:format=b,file=<dumpfile> <pid>

However, you need to be aware that heap dump files generated by different manufacturers ' JVMs have many differences in data storage formats and data storage content, and MAT is not a universal tool, and it does not handle all types of heap storage files. However, more mainstream manufacturers and formats, such as Sun, HP, SAP HPROF binary heap storage files, and IBM PHD heap storage files can be well resolved (you need to install additional plug-ins, please refer to the relevant instructions, this article does not explain in detail).

Then add production to your eclipse or tomcat.configuration of the. hprof file,

Then, on the parameter Settings page, set the parameters in the order of A, B: (-xx:+heapdumponoutofmemoryerror) Avoid write errors can copy

The program code that runs the error will see the following result:

< Span style= "FONT-SIZE:15PX; line-height:19.7600002288818px; Background-color:rgb (249,249,249) ">

then a file is generated. java_pid3708.hprof , this file is in the root directory of your project

Generate Analysis Reports

First, start the previous installation of the configured Memory Analyzer tool and select the menu item File-open heap dump to load the heap dump file that needs to be parsed. After the file is loaded, you can see the interface shown in 4:

Figure 4. Overview

With the above overview, we have a general understanding of memory usage. First check the series of files that the MAT generates.

Figure 5. File list

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.

Let's take a look at what is included in the generated report and help us find out what the problem is. You can generate a memory leak analysis report by tapping the Leak Suspects menu item on the toolbar, or simply click the Reports->leak Suspects link below the pie chart to generate the report.

Figure 6. Toolbar menu

Back to top of page

Analysis of three-step curve

Usually we use the following "three steps" to analyze the memory leak problem:

First, get an overall impression of the system memory state at the time the problem occurred.

The second step is to find the culprit that is most likely to cause a memory leak, usually the object that consumes the most memory

Next, take a closer look at the specifics of this large memory consumer and see if there are any unusual behaviors.

The following is a basic example of how to use the "three steps" to view production analysis reports.

View one of the reports: Overall status of memory consumption Figure 7. Memory Leak Analysis Report

7, the most visible on the report is a simple pie chart, from which we can clearly see that a suspicious object consumes 99% of the memory of the system.

A further description of this suspicious object is also available below the graph. We can see that the memory is consumed by the Java.util.Vector instance, and Com.ibm.oti.vm.BootstrapClassLoader is responsible for loading the object. This description is very short, but I'm sure you can find a lot of clues, such as which class takes up most of the memory, which component it belongs to, and so on.

Next, we should go further to analyze the problem, why a Vector will occupy the system 99% of the memory, who stopped the garbage collection mechanism of its recycling.

View report Two: Analyzing the problem

First, we briefly review the JAVA memory recycling mechanism, the garbage collection in memory space is done by the garbage collector (garbage COLLECTOR,GC), its core idea is: the virtual machine available memory space, that is, the object in the heap space, if the object is being referenced, It is then called a surviving object, and conversely, if the object is no longer referenced, it is a garbage object that can reclaim its occupied space for redistribution.

In the garbage collection mechanism, a set of elements is called the root element collection, which is a set of objects that are directly referenced by the virtual machine, such as the running thread object, the objects inside the system call stack, and the objects that are loaded by the Systems class loader. Each object in the heap space is called by a root element as the starting point for the layer. Therefore, an object is also referenced by a surviving root element, which is considered to be a surviving object and cannot be reclaimed for memory release. Therefore, we can parse the reference path of an object to the root element to analyze why the object cannot be reclaimed successfully. If an object is not required by any program logic but there is a case where the root element is referenced, we can say there is a memory leak.

Now, let's really look for a memory leak tour and click on the "Details" link to see a detailed analysis of the suspicious object 1 shown in 8.

Figure 8. Detailed analysis report for suspicious object 1

1. We look at the shortest path from the GC root element to the memory consumption aggregation point:

Figure 9. The shortest path from the root element to the memory consumption aggregation point

We can clearly see the entire reference chain, the memory aggregation point is a collection of a large number of objects, if you are familiar with the code, believe that this information should provide you with some ideas to find memory leaks.

Next, let's take a look at what's in this object collection and why it consumes so much memory.

Figure 10. Memory consumption aggregate Object information

In this diagram, we can see clearly that this object collection holds a large number of references to the person object, which is the memory leak that it causes.

Eclipse Memory Analyzer tips for using