JVM combat: use MAT for memory overflow troubleshooting

Memory overflow troubleshooting

Let's first understand the composition of the Java heap. For most applications, the Java Heap is the largest piece of memory managed by the Java virtual machine lock. The Java heap is a memory area shared by all threads, created when the virtual machine starts. The only purpose of this memory area is to store object instances, almost all object instances allocate memory here

The structure of the heap is as follows

. The specific division ratio of the new generation and the old generation is as follows

. The main function of the generation is to manage memory more efficiently.

Memory leak and memory overflow are 2 different concepts

Memory leak: The object is no longer used, but still occupies memory space and has not been released

Memory overflow: Not enough heap space, usually manifested as OutOfMemoryError, memory leaks usually lead to memory overflow

Analysis with Eclipse Memory Analyzer

There are many tools for analyzing heap memory, such as jvisualvm, but they are very tasteless. The most powerful tool is Eclipse Memory Analyzer (MAT for short)

Let's write a program to demonstrate the scenario of increasing memory

public class OomDemo {
    
    

    private static final int NUM = 1024;

    public static void main(String[] args) throws InterruptedException {
    
    
        List<byte[]> list = Lists.newArrayList();
        for (int i = 0; i < NUM; i++) {
    
    
            TimeUnit.SECONDS.sleep(1);
            list.add(new byte[NUM * NUM]);
        }
    }
}

Eclipse Memory Analyzer download address:
https://www.eclipse.org/mat/downloads.php

Or the above program, we set the following parameters when starting, so that the Dump file is automatically generated when the program memory overflows

-Xmx30m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/Users/peng

-Xmx30m: The maximum heap memory is 30m
-XX:+HeapDumpOnOutOfMemoryError: When an OOM occurs in the JVM, a DUMP file is automatically generated.
-XX:HeapDumpPath: Specify the file path, for example: -XX:HeapDumpPath=${directory}/java_heapdump.hprof. If no file name is specified, the default is: java_pid<pid>.hprof

The production environment is generally configured to automatically generate a DUMP file

when the heap overflows. When the memory overflows, a file is automatically generated, java_pid28598.hprof

Of course, you can also execute the following command to generate the dump file manually

jmap -dump:file=文件名字 进程id

Then use MAT to open the dump file and start the analysis. The analysis process is 3 steps

1. What are the objects that take up too much memory? (MAT Histogram)
2. Who is this object referenced by? (MAT dominator_tree)
3. Locate specific code (MAT thread_overview)

What are the objects that take up too much memory?

Click the button marked red to see that the byte[] array occupies the most memory

Who is this object referenced by?

Click the red button to see the reference relationship between the large object and the GC Root, which was originally referenced in the main thread

target specific code

Click the red button to see all the thread status in the application, such as method call links, and objects created in each method. In addition, it can be seen that the total number of threads is 6.

From the figure, we can see that the main thread executes to the 26th line of the OomDemo class at this time, that is, the following code

list.add(new byte[NUM * NUM]);

Well, the problem has been checked out, isn't it very simple. The troubleshooting process is very simple. The difficulty is how to solve it. If the code is written by yourself, it will be changed in a while. If the memory overflow caused by the code of some middleware requires you to have a basic understanding of the implementation of the middleware. Understand to solve!