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

Java third-party memory analysis tool MAT how to use, I believe that many inexperienced people do not know what to do, so this paper summarizes the causes of the problem and solutions, through this article I hope you can solve this problem.

Tags: java,troubleshooting,monitor,mat

In a word: MAT is a powerful memory analysis tool that can quickly and effectively help us find memory leaks and reduce memory consumption analysis tools, which will be explained below.

1 introduction

As mentioned in the previous article, the usage of in-memory heap is the focus of application performance monitoring, and dump can be used for further analysis of heap snapshots. Generally speaking, there are three ways for heap dump snapshots:

Add startup parameters automatic dump when OOM occurs: it is generally best to add-XX:+HeapDumpOnOutOfMemoryError and-XX:HeapDumpPath=logs/heapdump.hprof to the startup parameters of java applications, that is, to automatically dump heap snapshots when OOM occurs, but this method is quite lagging (you need to wait until after OOM occurs).

Manual dump on demand using commands: we can also do heap dump and thread dump manually using the jmap-dump:format=b,file=HeapDump.hprof tool

Manual dump using the tool: as mentioned in the previous article on jconsole and jvisualvm, jvisualvm has the ability to provide dump heap snapshots, just click on it.

So, for the files from dump, how to analyze them? Jvisualvm can directly load snapshot files for analysis, while the MAT introduced in this article is relatively more powerful in memory analysis, it can automatically detect possible problems (especially memory spills, memory leaks), you can also view class memory usage, method-level calls, etc., is a rare tool to analyze memory conditions.

2 introduction to MAT tools

MAT (Memory Analyzer tool) is a memory analyzer tool that is a fast and feature-rich heap memory analyzer that helps us find memory leaks and analyze high memory consumption problems. The official website is: https://www.eclipse.org/mat/, if you are interested, you can go up and have a look. With MAT, you can easily achieve the following functions:

Find the largest object because MAT provides a reasonable cumulative size for display (retained size)

Explore the object graph, including inbound and outbound references, that is, those that reference and derive from this object.

Find objects that cannot be recycled, and you can calculate the path from the garbage collector root to the related object

Find wasted memory, such as redundant String objects, empty collection objects, etc.

3 MAT tool installation

There are two ways to install MAT, one is to install as an eclipse plug-in, and the other is to install independently. Download the corresponding installation file in the official documentation of MAT at: https://www.eclipse.org/mat/downloads.php

To install using the eclipse plug-in, click help-> install new soft and add the plug-in address: http://download.eclipse.org/mat/1.9.0/update-site/ in the pop-up box. You can also download the offline plug-in package directly from the download page and install it offline.

Install independently, under windows, download Windows (x86) or Windows (x86 / 64) directly according to the system. When downloading, you can choose your own image and double-click to install it.

4. Use of MAT tool

MAT location is a memory analysis tool, and its main function is to analyze memory snapshots to help us find possible memory spills or memory leaks. Therefore, its main purpose is to find objects that take up a lot of memory and objects that cannot be recycled. MAT official document, the address is as follows: https://help.eclipse.org/2019-06/index.jsp?topic=/org.eclipse.mat.ui.help/welcome.html, describe the use of MAT, interested students can go up and have a look. The following mainly introduces the common concepts and functions of MAT.

In the following, take java-monitor-example (https://github.com/mianshenglee/my-example/tree/master/java-monitor-example) as an example). This example is a simple spring boot project in which a service object called by the user/oom API in controller constantly adds User objects through List members, resulting in the occurrence of OOM. The startup parameter of the application is-Xms64m-Xmx64m-XX:+HeapDumpOnOutOfMemoryError-XX:HeapDumpPath=$ {APP_HOME} / logs/heapdump.hprof.

4.1 MAT related concept Note 4.1.1 memory leaks and memory overflows

Memory leak: the object is no longer useful (not required by any program logic), and it is referenced by the root element, which cannot be automatically collected through the garbage collector. You need to find out the location and cause of the leaked code to determine the solution.

Memory overflow: all the objects in memory are still alive, and the heap allocation space of JVM is insufficient. You need to check the heap setting size (- Xmx and-Xms), and whether the code has an object life cycle that is too long and holds the state for too long.

4.1.2 references (strong references, soft references, weak references, virtual references)

Strong Ref (strong reference): strong reachability references, objects are stored in memory, only removed strong reachable, objects are recycled, usually we write code is Strong Ref.

Soft Ref (soft reference): corresponding to soft reachability, objects are kept as long as there is enough memory, and objects are not recycled until they are found to be tight and there is no Strong Ref. It can generally be used to implement caching, through the java.lang.ref.SoftReference class.

Weak Ref (weak reference): weaker than Soft Ref. When no Strong Ref is found, objects are recycled immediately without having to wait until memory is tight. Implemented through the java.lang.ref.WeakReference and java.util.WeakHashMap classes.

Phantom Ref (virtual reference): no objects are held in memory at all, you can only use Phantom Ref itself. It is generally used to perform a special cleanup process after entering the finalize () method, which is implemented through java.lang.ref.PhantomReference.

4.1.3 shallow heap and retained heap

Shallow heap: the amount of memory occupied by the object itself, that is, the sum of the object header plus member variables (not the values of member variables), such as a reference occupies 32 or 64bit, an integer occupies 4 bytes, long long occupies 8bytes, and so on. For example, if there is only one member variable int I in a simple class, then the shallo size of this class is 12 bytes, because the object header is 8 bytes and the member variable int is 4 bytes. The Shallow size of a regular object (not an array) is determined by the number and type of its member variables, and the shallow size of an array is determined by the type of array elements (object type, basic type) and array length.

Retained heap: if an object is released, it reduces the heap size of all objects that are referenced and thus released (including those that are released recursively) because of the object's release, which is the sum of all objects that can be removed from memory by GC after object X is reclaimed by the garbage collector. Compared to shallow heap,Retained heap, it can reflect the actual size of an object more accurately (if the object is released, retained heap can be released).

4.1.4 outgoing references and incoming references

Outgoing references: represents the outgoing node of the object (the object referenced by the object).

Incoming references: represents the incoming node of the object (the object referenced to the object).

4.1.5 Dominator Tree

Converting the object tree to Dominator Tree can help us quickly find the blocks that take up the most memory, and it can also help us to analyze the dependencies between objects. Dominator Tree has the following definitions:

Object X Dominator object Y if and only if all paths to Y in the object tree must pass through X.

The direct Dominator of object Y refers to the Dominator closest to Y in the object tree

Dominator tree is built using object trees. In Dominator tree, each object is a child of his direct Dominator.

The corresponding relationship between object tree and Dominator tree is as follows:

As shown in the figure above, because both An and B refer to C, C memory is not freed when An is released. So this piece of memory will not be calculated into the Retained Heap of An or B, so when the object tree is converted to Dominator tree, A, B, and C will be level.

4.1.6 Garbage Collection Roots (GC root)

In the execution of GC, whether an object is reachable or not is judged by object reachability, that is, whether the object's reference connection is connected to GC Root. A GC root refers to an object that can be accessed from outside the heap for the following reasons to make an object a GC root object.

System Class: classes loaded through the bootstrap/system classloader, such as java.util.* in rt.jar

JNI Local: a variable or method parameter in a JNI method

Global variables in the JNI Global:JNI method

Thread Block: variables in a thread, objects in a living thread must not be recycled

Thread: the thread in the active state

Busy Monitor: the wait (), notify () method, or synchronous object is called, such as calling synchronized (Object) or the current object after entering a synchronized method

Java Local: local variables, such as input parameters of a method or objects created inside the method that are still in the thread stack

A variable or method parameter in a Native Stack:Java method.

Finalizable: waiting for an object to run finalizer

Unfinalized: an object that has a finalize method but is not finalized and is not in the finalizer queue.

Unreachable: through an object where no other root is reachable, MAT marks it as root to facilitate analysis and recycling.

Java Stack Frame:java stack frame

Unknown

4.2 Leak Suspects automatic analysis of leakage

When OOM gets the heapdump.hprof file or manually dump the file, use MAT to open the file. When opened, the default prompt is whether to conduct a memory leak detection report (if Dump is skipped, you can also enter Run Expect System Test-> Leak Suspects on the toolbar from another entry), as shown in the following figure:

Select Yes to enter the content of the report, which will help us analyze the areas where there may be suspected memory leaks, and it will show the larger accumulated memory through the pie chart. As shown in the following figure:

As shown in the figure above, the report indicates that UserService occupies 76.73% of the memory, and this memory is in the Object [] array. Therefore, it is very likely that the number of arrays in this object is too large. Click Details to see more details:

In this detail, Shortest Paths To the Accumulation Point can show the shortest path to GC roots, thus analyzing which GC root is connected to which objects that are currently occupied by Retained Heap cannot be recycled, and in this case, GC root is the thread's local variable (java local). With Dominator Tree as the view of Accumulated Objects in Dominator Tree, you can easily see which of the objects that are "dominated" by the current object occupy more Retained Heap. In the figure, you can see that the objects are all in ArrayList, while there is an array of Object under ArrayList, and under the array are User objects. This will tell you what the problem is. You need to look at the code for this location to find out the cause of the excess User stored in this array.

Note: under the directory of the original heap dump file, MAT has compressed and packaged the contents of the report into a zip file, named "xxx_Leak_Suspects.zip". The whole report is a HTML format file, which can be opened and viewed directly by a browser, and it is convenient for report distribution and sharing.

4.3 histogram view to view the number and size of objects

Click the "Histogram View" in the Actions area of the Overview page or click the "histogram" button on the toolbar to display a list of histograms, which shows the number of instances of each Class class in the dimensions of the Class class, the amount of Shallow heap and Retained memory occupied, and can be sorted and displayed respectively. As shown in the following figure:

The concepts of Shallow Heap and Retained Heap have been discussed earlier. For java objects, their members are basically references. The real memory is on the heap and looks like a bunch of native byte [], char [], int [], so if you only look at the memory of the object itself, the amount is very small, and in most cases, the classes with a large number of instance objects in the Histogram view are basic types (usually at the top of the list), such as char [], String, byte [], so it is impossible to determine the specific class or method that caused the memory leak. From the figure above, you can directly see that there are a large number of User objects, which are sometimes not easy to see. You can use the group result by in the toolbar to sort by super class,class loader, etc. You need to pay special attention to the custom classLoader, as shown below:

In general, if the Histogram view shows a large number of instance objects that are not base types, but user-defined classes or suspected classes, focus on viewing. For further analysis, you can right-click and choose to use functions such as List objects or Merge Shortest Paths to GC roots to continue drilling data. List objects has outgoing references and incoming references respectively, so you can find out the references out of the object and through which references to the object. Merge Shortest Paths to GC roots can rule out anything that is not strongly referenced and find the reference path to GC root for this object. The ultimate goal is to find the objects that take up the most memory and cannot be recycled, and calculate the path from the root of the garbage collector to the related objects, so as to check the code according to this object path to find out the problem.

4.4 Dominator Tree View

Click "Dominator Tree View" in the Actions area of the Overview page or click the "open Dominator Tree" button on the toolbar to enter the Dominator Tree view. This view shows the objects with the largest Retained Heap footprint in the current heap memory and the tree structure of the objects that depend on them to survive in the dimensions of the instance objects. As shown below:

The view shows the instance object name, Shallow Heap size, Retained Heap size, and the percentage of the current object's Retained Heap in the heap. The graph is tree-structured, when the object of the previous level is recycled, then the child objects it refers to will be recycled, which is also the meaning of Dominator, when the recycling of the parent node will cause the child node to be recycled as well. From this view, you can easily find out the objects that take up the most memory in Retained Heap, and show which objects of some objects survived. In this example, you can see that the array referenced by ArrayList in UserService stores too many User objects.

4.5 Thread View to see how the thread stack is running

Click the "gear" button on the toolbar, you can open the Thread Overview view, you can view thread stack frame information, including thread object / thread stack information, thread name, Shallow Heap, Retained Heap, class loader, whether Daemon thread and other information. Combined with memory Dump analysis, you can see the local variables in the thread stack frame and the property values of the local variables in the object properties area at the lower left. If you press the example (shortest paths to GC root) above, you know that the thread Thread-12 takes up a lot of memory because GC-root takes up a lot of memory. In the thread view, you can focus on its properties, as shown in the following figure:

As you can see from the figure above, this thread calls the WithOOM method, using the variable UserService, while the variable uses userList, which contains a large number of User objects and takes up a lot of retained heap.

For the memory analysis of java applications, it is necessary to dump the memory of java applications. After generating memory snapshots, use MAT to analyze, find out large objects, find memory leaks or overflows, so as to analyze the code and solve the problem. In this article, the usage scenario, basic concepts, installation and use of MAT are introduced in detail. You can install it yourself, write a small example or take the example in this article to practice. Through this article, I hope it can help you analyze memory more conveniently and efficiently and solve the memory failure of java applications.

After reading the above, have you mastered how to use MAT, a third-party memory analysis tool for java? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

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.