brief introduction

Although Java has automated GC, there will be memory leaks. Of course, memory leaks in Java are different from those in C + +.

In C + +, all allocated memory objects need to be released manually by the programmer. However, this process is not required in Java. Everything is done automatically by GC. So is there no memory leak in Java?

To answer this question, we first need to define what is a memory leak. If sometimes objects that we no longer use can not be released by GC, it can be said that a memory leak has occurred.

The main reason for memory leakage is that the object life cycle in Java is long and short. If an object with a long life cycle references an object with a short life cycle, it may cause a de facto memory leak.

An example of a memory leak

Let's take an example of memory leak. First define a large object:

public class KeyObject {
    List<String> list = new ArrayList<>(200);
}

Then use it:

public class TestMemoryLeak {

    public static HashSet<Object> hashSet= new HashSet();

    public static void main(String[] args) throws InterruptedException {
        boolean flag= true;
        while(flag){
            KeyObject keyObject= new KeyObject();
            hashSet.add(keyObject);
            keyObject=null;
            Thread.sleep(1);
        }
        System.out.println(hashSet.remove(new KeyObject()));
    }
}

In this example, we put the new keyobject object into the HashSet. Then set keyobject to null.

However, because the class variable HashSet still retains the reference to keyobject, the keyobject object will not be recycled.

Use jfr and JMC to analyze memory leaks

Flight recorder (jfr) is mainly used to record events of JVM. We can analyze memory leakage from these events.

Jfr can be started by the following command:

java -XX:StartFlightRecording

Of course, we can also use the Java artifact jcmd to start jfr:

jcmd pid JFR.dump filename=recording.jfr path-to-gc-roots=true

Here we use JMC to graphically analyze the above example.

Turn on JMC, find our test program and turn on the flight recorder.

We can see that our object allocated 4MB of memory during the flight recorder, and then we can see that the overall memory usage is rising steadily.

Through analysis, we can see that memory usage is rising steadily, which is actually very suspicious.

Next, let's analyze it through the oldobjectsample event of the JVM.

OldObjectSample

Oldobjectsample is to sample objects with a long life cycle. We can check for potential memory leaks by studying these objects.

Here, let's focus on the old object sample event in the event browser. We can see the details of the event in the lower left.

Or you can use the jfr command to directly parse and output the events of interest:

jfr print --events OldObjectSample flight_recording_1401comflydeanTestMemoryLeak89268.jfr   > /tmp/jfrevent.log

Let's look at a specific output sample:

jdk.OldObjectSample {
  startTime = 19:53:25.607
  allocationTime = 19:50:51.924
  objectAge = 2 m 34 s
  lastKNownHeapUsage = 3.5 MB
  object =  [
    java.lang.Object[200]
  ]
  arrayElements = 200
  root = N/A
  eventThread = "main" (javaThreadId = 1)
  stackTrace = [
    java.util.ArrayList.<init>(int) line: 156
    com.flydean.KeyObject.<init>() line: 11
    com.flydean.TestMemoryLeak.main(String[]) line: 17
  ]
}

Lastknownheapuage is the usage size of heap. We can see from the log that this value is increasing all the time.

Allocationtime represents the time allocated by this object.

Starttime indicates the time when the object was dumped.

Object represents the allocated object.

Stacktrace represents the stack information allocated to this object.

From the above log, we can see that the 17th line in the main method is keyobject keyobject = new keyobject(); Constantly creating new objects.

Thus, we can conduct a deeper analysis and finally find the cause of memory leakage.