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 the introduction

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

  • Add startup parameters Automatically dump when OOM occurs: It is best to add all startup parameters of Java applications-XX:+HeapDumpOnOutOfMemoryErrorand-XX:HeapDumpPath=logs/heapdump.hprofAutomatically dump heap snapshots on OOM occurrence, but this approach is rather delayed (wait until OOM occurrence).
  • Manually dump on demand using the command: we can also use itjmap -dump:format=b,file=HeapDump.hprof <pid>Tools do heap dump and thread dump manually
  • Manually dump using a tool: for examplePrevious articlerightjconsoleandjvisualvmJvisualvm has the ability to dump heap snapshots with one click.

Dump files, how to analyze them? Jvisualvm can directly load snapshot files for analysis, while MAT introduced in this paper has a more powerful memory analysis function. It can automatically detect possible problems (especially memory overflow and memory leak), and can also check class memory occupation and method-level invocation in detail. Is a rare tool for analyzing memory conditions.

2 Introduction to MAT Tools

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

  • Find the largest object, because MAT offers to display a reasonable cumulative size (retained size)
  • Explore object diagrams, includinginboundandoutboundReferences, that is, references to and derived from this object.
  • Finding objects that cannot be collected computs the path from the garbage collector root to the related object
  • Find memory waste, such as redundant strings, empty collections, and so on

3 MAT Tool installation

MAT can be installed in two ways, one is installed as an Eclipse plug-in, the other is installed independently. In the official documentation of MAT have corresponding installation file to download, download address is: https://www.eclipse.org/mat/downloads.php

  • If you install using the Eclipse plug-in,help -> install new softClick on theADD, add the plug-in address in the pop-up box:http://download.eclipse.org/mat/1.9.0/update-site/Or you can download the offline plug-in package from the download page to install the plug-in in offline mode.
  • Independent installation, Windows, according to the system directly downloadWindows (x86)orWindows (x86_64), you can choose your own image when downloading, double-click to install.

4 MAT Tool Use

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

Below, in Java – monitor – example (https://github.com/mianshenglee/my-example/tree/master/java-monitor-example), for example, This example is a simple Spring Boot project, in which the service object called by the User /oom interface of a controller continuously adds the user object through the List member, resulting in oom. Application startup parameter is – Xms64m – Xmx64m – XX: + HeapDumpOnOutOfMemoryError – XX: HeapDumpPath = ${APP_HOME} / logs/heapdumps hprof.

4.1 Concepts related to MAT

4.1.1 Memory Leakage and Memory Overflow

  • Memory leaks: objects that are no longer useful (not needed by any program logic) and are referenced by root elements that cannot be automatically collected by the garbage collector and need to be resolved by finding out where the code is leaking and why;
  • Out of memory: Objects in memory are still alive, the JVM is running out of heap space, and needs to check the heap Settings (-xmx and -xMS) to see if the code has objects that are too long in life or hold state for too long.

4.1.2 Reference (Strong Reference, Soft Reference, Weak Reference, Virtual Reference)

  • Strong Ref: A reference to a Strong reachable object. The object is stored in memory and can only be reclaimed if the Strong Ref is removed.

  • Soft Ref(Soft Ref) : Corresponding to Soft reachability, objects are held as long as there is enough memory, and objects are reclaimed when memory is found to be tight and there is no Strong Ref. Generally can be used to implement caching, through the Java. Lang. Ref. SoftReference class implements.

  • Weak Ref: Weaker than Soft Ref. When a Strong Ref is not found, the object is reclaimed immediately without waiting until memory is tight. Through the Java. Lang. Ref. WeakReference and Java. Util. WeakHashMap class implements.

  • Phantom Ref: Does not hold any objects in memory at all, you can only use the Phantom Ref itself. Are commonly used in entering the finalize () method after special cleaning process, through the Java. Lang. Ref. PhantomReference implementation.

4.1.3 shallow heapandretained heap

  • shallow heap: specifies the memory occupied by the object itself. It is the sum of the object header plus the value of the member variable (not the value of the member variable). For example, a reference takes 32 or 64 bytes, an integer takes 4bytes, and a Long takes 8bytes. For example, a simple class has only one member variableint iSo this classshallo sizeIt’s 12 bytes, because the object header is 8 bytes, the member variableintIt’s 4 bytes. The Shallow size of a normal object (non-array) is determined by the number and type of its member variables, while the Shallow size of an array is determined by the type of the array element (object type, primitive type) and the length of the array.
  • retained heap: If an object is freed, the release of the object reduces the heap size of all objects (including recursively freed objects) referenced and then freed, i.e. the sum of all objects that can be removed from memory by the GC after object X is collected by the garbage collector. Compared with the shallow heap, the Retained heap can reflect the size of an object more accurately. (If the object is released, the Retained heap can be released.)

4.1.4 outgoing referenceswithincoming 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 into a Dominator Tree helps us quickly find the largest chunk of memory, and also helps us analyze dependencies between objects. Dominator Tree has the following definitions:

  • Object XDominator(governs) object Y if and only if all paths to Y in the object tree must go through X
  • Direct of object YDominatorIs the closest to Y in the object treeDominator
  • Dominator treeUse object tree to build out. inDominator treeEach object is his immediacyDominatorChild node of.

The mapping between object trees and Dominator trees is as follows:

As shown in the figure above, since both A and B reference C, C memory will not be freed when A is freed. Therefore, this piece of memory is not counted in the Retained Heap of A or B. Therefore, A, B, and C are flat when the object tree is transformed into A Dominator tree.

Garbage Collection Roots (GC root)

When GC is performed, objects are reclaimed by object reachability, that is, whether an object is reachability, that is, whether the reference connection of the object is connected to the GC Root. A GC root is an object that can be accessed from outside the heap, and an object can be a GC root object for the following reasons.

  • 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
  • JNI Global: global variable in JNI methods
  • Thread BlockA variable in a thread, and an object in a living thread must not be reclaimed
  • Thread: Active thread
  • Busy Monitor: Calls wait(), notify(), or synchronized objects, such as synchronized(Object) or the current Object after entering a synchronized method
  • Java Local: local variables, such as method input parameters or objects created inside the method that are still on the thread stack
  • Native Stack: a variable or method parameter in a Java method.
  • Finalizable: The object for which finalizer is to be run
  • UnfinalizedFinalized: has finalize methods, but it did not go through Finalized, and is not an object in the Finalizer queue.
  • Unreachable: Through objects that are unreachable by other root, MAT marks them as root for collection purposes.
  • Java Stack Frame: the Java stack frame
  • Unknown

Analyze the Leak automatically

When OOM obtains the heapdump.hprof file or manually dumps the file, use MAT to open the file. The default prompt for a memory Leak detection report (if you skip Dump, you can also enter the Run Expect System Test -> Leak Suspects on the toolbar from another portal), as shown below:

The choice is to enter the content of the report later, which will help us analyze the places that may be suspected of memory leakage. It will show the places with large accumulated memory usage through the pie chart. As shown below:

As shown in the figure above, it has been reported that UserService occupies 76.73% of the memory in the Object[] array. Therefore, it is most likely that the number of arrays in this object is too large. Click on Details for more Details:

The Shortest path To the Accumulation Point can show the Shortest path To GC roots. Therefore, it can be analyzed that the currently Retained Heap occupying a large number of objects cannot be recovered because it is connected To the GC root. In this example, GC root is the thread’s local variable (Java Local). Retained Objects in Dominator Tree Viewed from the Dominator Tree, we can easily see which Retained Heap is larger among the Objects “dominated” by the current object. You can see that all the objects are in an ArrayList, and under an ArrayList there’s an Object, and under an array there’s a User Object. You can see what the problem is. For this location, you need to look at the code to find out what causes the array to store too many users.

Note: In 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 entire report is an HTML file, which can be opened and viewed by a browser, facilitating report distribution and sharing.

4.3 Histogram View Views the number and size of objects

To display a list of histograms, click the “Histogram View” in the Actions area of the Overview page, or click the “Histogram” button in the toolbar. It displays the number of instances, Shallow heap and Retained memory of each Class by Class dimension, and can be sorted separately. As shown below:

Shallow Heap and Retained Heap have been described previously. For Java objects, the members are basically references. The real memory is on the heap, which appears to be a bunch of native byte[], char[], and int[], so if you look at only the memory of the objects themselves, the amounts are small. In most cases, the classes that are seen with a high number of instance objects in the Histogram view are the basic types (usually first). Such as char[], String, and byte[], so it is impossible to identify the class or method that caused the memory leak from these. Group result by can be sorted by super class,class loader, etc. Special attention should be paid to custom classLoader, as shown in the following figure:

In general, if the Histogram view shows a large number of instance objects that are not base types, but are user-defined or suspect classes, focus your attention. To further analyze, right click and select List Objects or Merge Shortest Paths to GC Roots to drill data. The list objects have outgoing references and incoming References respectively, which can find out the references from this object and through which references to this object. Merge Shortest Paths to GC roots to exclude all non-strong references and find the GC root reference path for the object. The ultimate goal is to find the biggest and uncollectable objects, calculate the path from the garbage collector root to the related objects, and then check the code against that object path to find the problem.

4.4 Dominator Treeview

To enter the Dominator Tree view, click “Dominator Tree View” in the Actions area on the Overview page or click “Open Dominator Tree” on the toolbar. This view displays the largest Retained Heap of objects in the current Heap, as well as the tree structure of the objects that rely on them. The diagram below:

The Retained Heap view displays the name of the instance, the Shallow Heap size, the Retained Heap size, and the fraction of the Retained Heap for the current object in the entire Heap. The graph is a tree structure, and when the next-level object is reclaimed, all the children it refers to are reclaimed. This is what Dominator is all about. When a parent node is reclaimed, its children are reclaimed. Using this view, you can easily identify the objects that occupy the largest fraction of Retained Heap memory, and express the objects that live because of them. In this example, you can see that the array referenced by ArrayList in UserService stores too many User objects.

4.5 Thread View View the running status of the thread stack

Click the “gear” button on the toolbar to open the Thread Overview view. You can view the stack frame information of a Thread, including the Thread object/Thread stack information, Thread name, Shallow Heap, Retained Heap, class loader, whether or not a Daemon Thread, etc. In conjunction with in-memory Dump analysis, you can see the local variables in the thread stack frame, as well as the property values of the local variables in the object properties area in the lower left. If following the above example (shortest Paths to GC root), know is due to Thread Thread 12 is GC-root occupies a large memory, in the Thread view, you can focus on its attributes, as shown below:

As can be seen from the above figure, this thread calls WithOOM method and uses the variable UserService, while the variable uses userList. It contains a large number of User objects and consumes a large number of retained heap.

5 concludes

For the memory analysis of Java applications, it is necessary to dump the memory of Java applications. After the memory snapshot is generated, MAT is used for analysis to find out large objects and memory leakage or overflow, so as to analyze the code and solve problems. This paper introduces the usage scenarios, basic concepts, installation and use of MAT in detail. You can install MAT by yourself, write a small example or take the example in this paper for practice. Through this article, I hope to help you more convenient, more efficient analysis of memory, to solve the memory problems of Java applications.

Parameter data

  • MATWebsite:https://www.eclipse.org/mat/
  • MATDownload:http://www.eclipse.org/mat/downloads.php
  • MATUser Manual:https://help.eclipse.org/2019-06/index.jsp?topic=/org.eclipse.mat.ui.help/welcome.html
  • Shallow and retained sizes:https://www.yourkit.com/docs/java/help/sizes.jsp
  • Analyzing online Faults using the Eclipse Memory Analyzer Tool (MAT)https://www.cnblogs.com/trust-freedom/p/6744948.html
  • Example code address:https://github.com/mianshenglee/my-example/tree/master/java-monitor-example

reading

  • Java Application Monitoring (1)- Application monitoring techniques that Java programmers should know about
  • Java Application Monitoring (2)- Secrets of Java commands
  • Java Application Monitor (3)- Do you master these command line tools
  • Java Application Monitoring (4)- Online problem detection routines
  • Java Application Monitoring (5)- Visual monitoring tools