关于java:troubleshoot之使用JFR解决内存泄露

8次阅读

共计 2362 个字符,预计需要花费 6 分钟才能阅读完成。

简介

尽管 java 有自动化的 GC,然而还会有内存泄露的状况。当然 java 中的内存泄露跟 C ++ 中的泄露不同。

在 C ++ 中所有被调配的内存对象都须要要程序员手动开释。然而在 java 中并不需要这个过程,一切都是由 GC 来主动实现的。那么是不是 java 中就没有内存泄露了呢?

要答复这个问题咱们首先须要界定一下什么是内存泄露。如果说有时候咱们不再应用的对象却不能被 GC 开释的话,那么就能够说产生了内存泄露。

内存泄露的次要起因就是 java 中的对象生命周期有长有短。如果长生命周期的对象援用了短生命周期的对象,就有可能造成事实上的内存泄露。

一个内存泄露的例子

咱们举一个内存泄露的例子,先定义一个大对象:

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

而后应用它:

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()));
    }
}

在这个例子中,咱们将 new 进去的 KeyObject 对象放进 HashSet 中。
而后将 keyObject 置为空。

然而因为类变量 hashSet 还保留着对 keyObject 的援用,所以 keyObject 对象并不会被回收。

留神,最初一行咱们加了一个 hashSet.remove 的代码,来应用类变量 hashSet。
为什么要这样做呢?这样做是为了避免 JIT 对代码进行优化,从而影响咱们对内存泄露的剖析。

应用 JFR 和 JMC 来剖析内存泄露

Flight Recorder(JFR) 次要用来记录 JVM 的事件,咱们能够从这些事件中剖析出内存泄露。

能够通过上面的指令来开启 JFR:

java -XX:StartFlightRecording

当然咱们也能够应用 java 神器 jcmd 来开启 JFR:

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

这里咱们应用 JMC 来图形化剖析一下下面的例子。

开启 JMC,找到咱们的测试程序,关上航行记录器。

能够看到咱们的对象在航行记录器期间调配了 4MB 的内存,而后看到整体的内存使用量是稳步回升的。

咱们什么时候晓得会有内存泄露呢?最简略的必定就是 OutOfMemoryErrors,然而有些很荫蔽的内存泄露会导致内存应用缓步上涨,这时候就须要咱们进行粗疏的剖析。

通过剖析,咱们看到内存应用在稳步上涨,这其实是很可疑的。

接下来咱们通过 JVM 的 OldObjectSample 事件来剖析一下。

OldObjectSample

OldObjectSample 就是对生命周期比拟长的对象进行取样,咱们能够通过钻研这些对象,来查看潜在的内存泄露。

这里咱们关注一下事件浏览器中的 Old Object Sample 事件,咱们能够在左下方看到事件的详情。

或者你能够应用 jfr 命令间接将感兴趣的事件解析输入:

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

咱们看一个具体的输入 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
  ]
}

lastKnownHeapUsage 是 heap 的应用大小,从日志中咱们能够看到这个值是始终在减少的。

allocationTime 示意的是这个对象调配的工夫。

startTime 示意的是这个对象被 dump 的工夫。

object 示意的是调配的对象。

stackTrace 示意的是这个对象被调配的 stack 信息。

留神,如果须要展现 stackTrace 信息,须要开启 -XX:StartFlightRecording:settings=profile 选项。

从下面的日志咱们能够剖析得出,main 办法中的第 17 行,也就是 KeyObject keyObject= new KeyObject(); 在一直的创立新的对象。

从而咱们能够进行更深层次的剖析,最终找到内存泄露的起因。

总结

本文通过 JFR 和 JMC 的应用,介绍了如何剖析内存泄露。心愿大家可能喜爱。

本文作者:flydean 程序那些事

本文链接:http://www.flydean.com/jvm-diagnostic-memory-leak/

本文起源:flydean 的博客

欢送关注我的公众号: 程序那些事,更多精彩等着您!

正文完
 0