Briefly to demonstrate the OOM analysis and combat.

Directly on the code:

public class Demo4 {

    public static void main(String[] args) {
        List<Dandan> list = new ArrayList<>();
        while (true){
            list.add(new Dandan());
        }
    }
}

class Dandan{

}

Copy the code

The JVM parameters:

-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -Xms10m -Xmx10m -XX:+PrintGCDetails -Xloggc:gc_dandan.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./

Log after run:

java.lang.OutOfMemoryError: Java heap space Dumping heap to ./java_pid22788.hprof ... Heap dump file created [13244840 bytes in 0.050 secs] the Exception in the thread "is the main" Java. Lang. OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Arrays.java:3210) at java.util.Arrays.copyOf(Arrays.java:3181) at java.util.ArrayList.grow(ArrayList.java:267) at java.util.ArrayList.ensureExplicitCapacity(ArrayList.java:241) at java.util.ArrayList.ensureCapacityInternal(ArrayList.java:233) at java.util.ArrayList.add(ArrayList.java:464) at com.hailintang.demo.jdk8.gc.oom.Demo4.main(Demo4.java:11) Process finished with exit code 1Copy the code

java.lang.OutOfMemoryError: Java heap space

First, it tells us exactly where the memory leak is: the heap

Because the configuration parameters: – XX: + HeapDumpOnOutOfMemoryError

Java_pid22788. hprof: java_pid22788.hprof: java_pid22788.hprof: java_pid22788.hprof: java_pid22788.hprof

The name format is java_pid(program process number).hprof

The next step, of course, is to use MAT for analysis: hprof files

What should we focus on before analyzing?

  • First, which objects take up a lot of memory.
  • Second, by whom the object is referenced. (To know why it can’t be released)
  • Third, locate the specific line of code and analyze the problem

Open the hprof file and check the red box if you want to analyze memory leaks.

Here, let’s first look at which objects take up a lot of memory. Press the red box Histogram button

First, which objects take up a lot of memory

Enter the Histogram page

When you enter the page, you can immediately see which object is taking up the most memory.

For example here is obvious class com. Hailintang. Demo. Jdk8. Gc. Oom. Dandan this class takes up too much memory.

It says here that there are 360,146 objects of this Dandan class. So far, we’ve tentatively determined that the Dandan object is taking up a lot of memory.

Second, by whom the object is referenced

Next, let’s look at who references the overmemorized object.

In this case, you need to use MAT’s Dominator-tree: the tool used to analyze the relationship between objects.

Then you can see which threads are creating too many objects.

For example, the thread that creates too many objects is the main thread

And then you expand the main thread to see what object was created

Cause the main thread to take up so much memory

Check it out, man

Found to be a java.lang.object [] array.

Continue to spread

We found that the array was full of Dandan objects

At this point, the truth comes out

After layer upon layer. The object created by the thread is mapped to Dandan, the object that took up too much memory in the Histogram interface.

Third, locate the specific line of code and analyze the problem

Once you find the reference, the last step is to figure out which line of code is creating this many objects?

Another view, thread_overview, is required at this point. As shown in the red circle

Thread_overview shows all threads in the JVM, each thread, its current method call stack, and what objects each method created.

Note: stack, last in, first out, so when you look at the graph, look from the bottom up

The Thread_Overview screen is displayed

Find the main Thread and click on it

You can quickly see Demo4.java:11

At this point, you’re not so sure. I need to click on it to continue

You can see that a lot of Dandan objects are actually created here.

Here you combine the code for kohlrabi:

Ok, so you’ve basically figured out which line of code is causing the OOM problem.

Just to summarize

conclusion

Our methodology is:

  • First, which objects take up a lot of memory. —— corresponding HISTOGRAM of MAT
  • Second, by whom the object is referenced. —— corresponding to MAT’s Dominator-tree
  • Third, locate the specific line of code and analyze the problem —- corresponds to MAT’s Thread-overview

Then, we conducted the investigation step by step according to the methodology and the MAT tool. The goal is to find out which lines of code are causing OOM problems.

This is an easy OOM question. This is just a Demo to show you how to use MAT to analyze OOM problems.

For complicated projects, in step 3, if the problematic code is caused by other third-party middleware, such as Tomcat, Jetty, RPC and other frameworks in OOM, you need to be familiar with these middleware to locate the problem. If the offending code is business code, then you need to invite the development engineer responsible for the project to locate the code.

In fact, we can completely locate the OOM problem MAT methodology, with practical work.

Well, that’s all for today’s technology sharing.

If you have any questions, please leave a comment.