绑定完请刷新页面
取消
刷新

分享好友

×
取消 复制
troubleshoot之:使用JFR解决内存泄露
2020-08-12 13:24:08

简介

虽然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的使用,介绍了如何分析内存泄露。希望大家能够喜欢。

分享好友

分享这个小栈给你的朋友们,一起进步吧。

程序那些事
创建时间:2020-06-17 07:11:38
最通俗的解读,最深刻的干货,最简洁的教程,众多你不知道的小技巧,尽在公众号:程序那些事!
展开
订阅须知

• 所有用户可根据关注领域订阅专区或所有专区

• 付费订阅:虚拟交易,一经交易不退款;若特殊情况,可3日内客服咨询

• 专区发布评论属默认订阅所评论专区(除付费小栈外)

栈主、嘉宾

查看更多
  • flydean程序那些事
    栈主

小栈成员

查看更多
  • ☀️
  • 小天
  • 林昆
  • 背后
戳我,来吐槽~