性能文章>实战案例:记一次dump文件分析历程>

实战案例:记一次dump文件分析历程转载

4月前
395215

一、背景

今天下午,正酣畅淋漓的搬砖,突然运维同事在群里通知,核心服务某个节点内存异常,服务假死。神经一下子紧张起来,赶紧跑到运维那边观察现象。

观察的结果是服务内存溢出,该服务是核心服务,分配了5G内存。运维在转存快照后,立刻重启服务后正常。在接下来的一段时间里,另一台服务节点也发生了同样的情况。

二、分析过程

这个服务是另外一个同事负责开发的,本着学习的态度,在拿到运维转存的dump文件后,就准备尝试着分析下问题,由于之前没有类似的经历,于是先在网上查了下一般怎么分析类似的问题。

首先尝试使用MAT(Memory Analyzer)工具进行分析,下载后就准备载入dump文件,很不幸由于dump文件过大,载入失败了,于是调大了内存大小,尝试再次载入,但此时这个文件不再尝试重新载入,直接提示载入失败。

先不纠结工具的问题,然后网上说JDK自带的jvisualvm也可以用来分析dump文件, 但也遇到了同样内存不足的问题,再尝试修改jvisualvm的内存限制后, 成功载入了。

看到的界面是这样的,很明显看到char[]占用了近70%的内存,接近4G,这太不正常了,点进去看对应的实例(加载的非常慢,需要耐心)。

在实例数界面中看到实例数达到了千万级,大部分都是一些文件的路径字符串信息。在业务中,我们会生成很多临时文件,然后这些临时文件会删除,这里面大部分保存的是这些临时文件路径。

到这里导致内存泄露的原因似乎找到了,但好像又还不够,是什么原因导致这些临时变量没有被回收呢。

回到家后,还是想着这个事情,于是又开始研究起来,这个时候想起来可以再用MAT试着分析下,毕竟据说工具很强大。重启了电脑之后,经过漫长的等待,载入成功了(果然重启能解决一切问题)。

MAT的界面是这样的,里面包含的信息比较多,对于我这个菜鸟来说,确实一下子不知道看哪里。
那就一个个慢慢看吧,Histogram里面的与使用jvisualvm中看到的信息是相同的。

接下来进入到Dominator Tree视图, 列出当前存活的对象的内存大小,这看起来像是我需要关注的重点。然后查了下这个类 java.io.DeleteOnExitHook 与 内存泄露的相关问题。

这个问题在下面两个链接中给出了说明,大概意思是在删除文件使用 File.deleteOnExit() 方法时,并不是立刻删除文件,而是将该文件路径维护在类DeleteOnExit的一个LinkedHashSet中,最后在JVM关闭的时候,才会去删除这里面的文件,这个方法不能用于长时间运行的服务。
https://stackoverflow.com/questions/40119188/memory-leak-on-deleteonexithook
https://bugs.openjdk.java.net/browse/JDK-6664633

上面的描述,通过源码和JDK文档也都得到了证明。

// java.io.File
// Requests that the file or directory denoted by this abstract pathname be deleted when the virtual machine terminates.
public void deleteOnExit() {
	SecurityManager security = System.getSecurityManager();
	if (security != null) {
		security.checkDelete(path);
	}
	if (isInvalid()) {
		return;
	}
	DeleteOnExitHook.add(path);
}

// java.io.DeleteOnExitHook
private static LinkedHashSet<String> files = new LinkedHashSet<>();

static synchronized void add(String file) {
	if(files == null) {
		// DeleteOnExitHook is running. Too late to add a file
		throw new IllegalStateException("Shutdown in progress");
	}

	files.add(file);
}

三、结论

问题定位于File.deleteOnExit()方法的调用,导致内存泄漏。调用该方法只会将需要删除文件的路径,维护在类DeleteOnExit的一个LinkedHashSet中,在JVM关闭时,才会去真正执行删除文件操作。这样导致DeleteOnExitHook这个对象越来越大,最终内存溢出。

File.delete()File.deleteOnExit() 的区别:
当调用delete()方法时,直接删除文件,不管该文件是否存在,一经调用立即执行
当调用deleteOnExit()方法时,只是相当于对deleteOnExit()作一个声明,当程序运行结束,JVM终止时才真正调用deleteOnExit()方法实现删除操作。

我写了下面这个测试方法,对比 delete()deleteOnExit()的区别,现象会比较明显。使用deleteOnExit时是在文件全部创建,JVM关闭的时候,才一个个删除文件,delete会立刻删除文件。(所以这个方法的使用场景是怎样的,我就不太清楚了)

public static void loopTest() throws IOException {
	String root = "D:\\C_Temp\\files\\";

	File path = new File(root);
	if (!path.exists()) {
		path.mkdirs();
	}
	int i = 0;
	while (i < 40000) {
		File file = new File(path, "Hello-" + i + ".txt");
		file.createNewFile();
		file.delete();
//            file.deleteOnExit();
		i++;
	}
}

四、收获

本次排查经历最大的收获就是尝试利用工具分析dump文件,以前对这种都是望而却步,感觉很难。但这次带着问题去分析、思考,这样下来也不算过于复杂。有些问题不是问题本身难,是自己把它想得很难。

下面是本次的一些思考和踩过的坑,以作备忘。

1. 获取dump文件有两种方法

1)通过 jmap 工具生成可以生成任意Java进程的dump文件

# 先找到PID
ps -ef | grep java

# jmap 转存快照
jmap -dump:format=b,file=/opt/dump/test.dump {PID}

2)通过配置JVM启动参数

#  当程序出现OutofMemory时,将会在相应的目录下生成一份dump文件,如果不指定选项HeapDumpPath则在当前目录下生成dump文件
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/opt/dumps

2. MAT需要JDK11才能运行

解决办法是,打开MAT的安装目录,有一个配置文件MemoryAnalyzer.ini。打开这个文件,在文件中指定JDK版本即可。新增两行配置:

-vm D:/jdkPath/bin/javaw.exe

**3. 在使用jvisualvm分析大的dump文件时,堆查器使用的内存不足

修改JAVA_HOME/lib/visualvm/etc/visualvm.conf文件中 visualvm_default_options="-J-client -J-Xms24 -J-Xmx256m",然后重启jvisualVM即可

4. MAT修改内存空间

分析堆转储文件需要消耗很多的堆空间,为了保证分析的效率和性能,在有条件的情况下,建议分配给 MAT 尽可能多的内存资源。两种方式分配内存资源给 MAT:
1)修改启动参数 MemoryAnalyzer.exe -vmargs -Xmx4g
2)编辑文件 MemoryAnalyzer.ini 添加 -vmargs – Xmx4g

这里也列一个代办项

  • 学习MAT工具的使用

参考的一些文章:

作者:Hans_Hu

个人博客:https://www.cnblogs.com/hans-hu/ 

文章来源:博客园

原文链接:https://www.cnblogs.com/hans-hu/p/15999074.html

请先登录,查看1条精彩评论吧
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

不起眼,但是足以让你有收获的JVM内存分析案例
分析 这个问题说白了,就是说有些int[]对象不知道是哪里来的,于是我拿他的例子跑了跑,好像还真有这么回事。点该 dump 文件详情,查看相关的 int[] 数组,点该对象的“被引用对象”,发现所
从一起GC血案谈到反射原理
前言 首先回答一下提问者的问题。这主要是由于存在大量反射而产生的临时类加载器和 ASM 临时生成的类,这些类会被保留在 Metaspace,一旦 Metaspace 即将满的时候,就会触发 Fu
关于内存溢出,咱再聊点有意思的?
概述 上篇文章讲了JVM在GC上的一个设计缺陷,揪出一个导致GC慢慢变长的JVM设计缺陷,可能有不少人还是没怎么看明白的,今天准备讲的大家应该都很容易看明白 本文其实很犹豫写不写,因为感觉没有
协助美团kafka团队定位到的一个JVM Crash问题
概述 有挺长一段时间没写技术文章了,正好这两天美团kafka团队有位小伙伴加了我微信,然后咨询了一个JVM crash的问题,大家对crash的问题都比较无奈,因为没有现场,信息量不多,碰到这类问题我
又发现一个导致JVM物理内存消耗大的Bug(已提交Patch)
概述 最近我们公司在帮一个客户查一个JVM的问题(JDK1.8.0_191-b12),发现一个系统老是被OS Kill掉,是内存泄露导致的。在查的过程中,阴差阳错地发现了JVM另外的一个Bug。这个B
JVM实战:优化我的IDEA GC
IDEA是个好东西,可以说是地球上最好的Java开发工具,但是偶尔也会卡顿,仔细想想IDEA也是Java开发的,会不会和GC有关,于是就有了接下来对IDEA的GC进行调优 IDEA默认JVM参数: -
不起眼,但是足以让你收获的JVM内存案例
今天的这个案例我觉得应该会让你涨姿势吧,不管你对JVM有多熟悉,看到这篇文章,应该还是会有点小惊讶的,不过我觉得这个案例我分享出来,是想表达不管多么奇怪的现象请一定要追究下去,会让你慢慢变得强大起来,
如何通过反射获得方法的真实参数名(以及扩展研究)
前段时间,在做一个小的工程时,遇到了需要通过反射获得方法真实参数名的场景,在这里我遇到了一些小小的问题,后来在部门老大的指导下,我解决了这个问题。通过解决这个问题,附带着我了解到了很多新的知识,我觉得