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

This article shows you how to use jmap and MAT for heap memory overflow analysis, the content is concise and easy to understand, can definitely brighten your eyes, through the detailed introduction of this article, I hope you can get something.

Jmap:Java memory Mapping tool

The jmap (Memory Map for Java) command is used to generate heap dump snapshots (commonly referred to as heapdump or dump files). In addition, there are several ways to obtain dump files: using the JVM parameter option-XX:+HeapDumpOnOutOfMemoryError parameter, you can let the virtual machine generate dump files automatically after an OOM exception occurs, and set the dump file path through-XX:HeapDumpPath=path (sometimes the dump file may not be automatically exported when the dump file is large, so you need to use jmap-dump to export manually) Through the-XX.+HeapDumpOnCtrlBreak parameter, you can use the [Ctrl] + [Break] key to let the virtual machine generate the dump file, or on the Linux system, you can "scare" the virtual machine by sending the process exit signal through the Kill-3 command, or you can get the dump file.

The purpose of jmap is not just to get the dump file, it can also query the details of the finalize execution queue, Java heap, and permanent generation, such as space usage, which collector is currently used, and so on. Like the jinfo command, many features of jmap are limited on the Windows platform, except for the-dump option for generating dump files and the-histo option for viewing instances of each class and footprint statistics, which are available on all operating systems. Other options can only be used under Linux/Solans. Its official document address is: https://docs.oracle.com/javase/8/docs/technotes/tools/unix/jmap.html

Jmap command format: jmap [option] vmid

C:\ Users\ Administrator > jmap-helpUsage: jmap [option] (to connect to running process) jmap [option] Open Heap Dump, open the dump file we generated above

After clicking finish, you will see the following interface:

From the figure above, you can see its main functions:

1. Histogram can list the objects in memory, the number and size of objects (the unit of object size is byte).

2. Dominator Tree can list the size and percentage occupied by objects.

3.Top consumers lists the largest objects graphically.

4.Leak Suspects automatically analyzes the memory leak through MA and reports on the possible causes of memory leaks.

In MAT's chart, there are some common options:

List objects-- with outgoing references: view the external object references held by this object.

List objects-- with incoming references: see which external objects this object is referenced by.

Show objects by class-- with outgoing references: view external object references held by this object type

Show objects by class-- with incoming references: see which external objects this object type is referenced by

Paths to gc root: displays the path to the following node for different types of references (strong reference, weak reference, virtual reference, soft reference).

Merge shorest path to gc root: merging the shortest path to the root node

Shallow size: the amount of memory consumed by the object itself, and the object that does not contain its reference, that is, the sum of the object header plus member variables (not the values of member variables).

Retained size: is the object's own shallow size, plus the sum of the shallow size that can be accessed directly or indirectly from the object. In other words, retained size is the sum of the memory that the object can be reclaimed after it has been GC. This needs to be paid more attention to. Generally speaking, objects with large Retained size are related to memory overflows.

For the object1,object1 size on the left of the image above, the size is shallow size,object1 and all blue objects are retained size that are directly or indirectly referenced by the object. Object4 is also referenced by gc roots in the figure, so retained size does not include this.

Top consumers view

Top consumers is shown in the following figure: this shows which objects are the largest in memory, which are their corresponding classes, and which are the class loader classloader. You can see that objects of the MemoryController class occupy more than 50% of 15MB's heap memory, which is very abnormal. I only have screenshots about objects here, and there will be classes, class loaders, and package-related information, so you can take a look at them for yourself.

Leak Suspects view

Leak Suspects (memory leak Analysis) is shown in the following figure: the memory leak analysis report suspects two suspected memory leaks, which shows that Problem Suspect 1 shows that MemoryController class objects occupy 57.74% of the memory, which is accumulated in an Object [].

Next, we click Details in Problem Suspect 1 to view the details, and we can see the following: you can also see that userList in MemoryController takes up more than 15 megabytes of memory, and user objects are stored in userList. These user objects are all stored in Object [] elementData in ArrayList. Just check the ArrayList source code. In addition, you can see that it was created in the thread org.apache.tomcat.util.threads.TaskThread @ 0xfecb3220 http-nio-9999-exec-3 Thread.

Transient Object [] elementData; / / non-private to simplify nested class access/** * Constructs an empty list with an initial capacity of ten. * / public ArrayList () {this.elementData = DEFAULTCAPACITY_EMPTY_ELEMENTDATA;}

By right-clicking, you can view the external object references held by this object through List objects-with outgoing references:.

Histogram view

In the Histogram view, we can delete and select using regular expressions. I filter according to com.wkp. We can see that there are 111305 user objects. We can find the GC Roots of user objects through merge shorest path to gc roots, and eliminate virtual references, weak references, soft references and so on through exclude all phantom/weak/soft etc.references.

If you look at the GC Roots as follows, you can see that the thread http-nio-9999-exec-3 Thread is GC Roots. It is because there are too many user objects stored in the userList in this thread that the heap memory burst and memory overflow occurs.

Dominator Tree view

Dominator Tree can list information such as the size and percentage of space occupied by objects. You can see that similar to the above view, you can see that the Shallow Heap of the MemoryController object is only 16byte, but the Retained Heap has reached the number of 15MB, which is extremely abnormal, which is the key suspect object of memory leak.

On the use of jmap and MAT first introduced here, because this memory overflow is manually constructed, it is relatively easy to find, really to the production above we need to carefully eliminate. In general, find out the cause of the memory overflow and summarize the following two points:

1. First of all, let's take a look at the largest data in retained size. Generally speaking, memory is intended to solve the problem of memory leakage, which can be done through actions such as Top Consumers or donimator tree.

two。 After finding the largest data, use list objects-- with outgoing references to see which objects are held.

The above is how to use jmap and MAT for heap memory overflow analysis. Have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

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.