这个案例你可以直接拿去用。

最新推荐文章于 2023-06-20 11:33:18 发布

Java面试那些事儿

最新推荐文章于 2023-06-20 11:33:18 发布

阅读量1.9k

点赞数 1

文章标签： java 开发语言

本文链接：https://blog.csdn.net/HongYu012/article/details/123548101

版权

给大家分享一个生产问题排查案例。这个案例你甚至都不需要改，张口就可以说：这个问题是我解决的。

因为这个案例本身就不复杂，难的是真正动手去做。

而只要涉及到“真正动手”去做，就能拦下 80% 的人。

背景

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

观察的结果是服务内存溢出，该服务是核心服务，分配了 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 文件有两种方法 **

第一张是可以通过 jmap 工具可以生成任意 Java 进程的 dump 文件

# 先找到PID
ps -ef | grep java

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

第二种是通过配置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：

修改启动参数 MemoryAnalyzer.exe -vmargs -Xmx4g
编辑文件 MemoryAnalyzer.ini 添加 -vmargs – Xmx4g

引出一个面试题

怎么样，看完这个排查方案是不是很简单，很清晰。

是不是有一种：我上我也行的错觉？

然而实际情况是怎么样的呢？

大概率的情况是这样：哎呀，这个 dump 文件怎么这么大啊。MAT 也打不开啊。怎么回事啊。等了半天没反应啊。算了算了，等组里大佬分析完了我问一句就行了。

只有动手，才是真正收获的第一步。

我觉得这个案例，如果是 3 年以内经验的同学在面试的时候，面试官问你下面这个问题的时候，你就可以拿出来说：

你在工作中遇到过什么印象深刻的困难呀？

这个问题，不一定是要考你有多么深的技术深度。

比如这个案例，技术深度就不是那么高。但是你可以把这个案例拿出来说。

至少如果面试官是我的话，我会觉得很不错，自己动手去分析了，也有探索过程中也遇到了一些阻碍，但是自己克服了，最终也得到了令人信服的结论，同时自己也学习到了很多新的只是，认识到了自己的不足之处。

这里面体现的是你的主观能动性，自己动手的能力，和技术深度一样重要。

当然了，这个问题，如果你是面试的技术大头兵岗位，三五年以上的经验，说这个案例就有点不“惊艳”了，最好还是往技术的深度答。

但是很多同学又觉得：自己工作很顺利啊，在技术上好像也没碰到啥印象深刻的困难。

关于这个文章，我之前就说过：这玩意，你就得自己平时工作中多积累，多观察相关的案例，然后记录下来。

可以把观察的目光放的长远一点，不一定非得是自己所在的项目组遇到的问题，也可以是其他的项目组遇到的问题。

这里就需要自己有一个情报收集的能力，和对于技术的敏感度。

一听到这问题就应该要知道：这是一个好素材呀，可以深入了解一下。

这个问题都不一定是你解决的，但是你要清楚的知道来龙去脉，就可以包装成自己的经历。

面试官是察觉不出来的。

而且我一直认为，适度的包装，也不算是面试造假。

当然了，这个方向你也可以去背。

但是不能纯粹的背诵，得适当的去扩展。

比如我之前分享过这样的一篇文章：

这个生产案例，好，很好，非常好。

这个案例从最开始 Dubbo 调用超时的这个表象，分别从数据库、GC、网络、链路追踪等各个角度去分析了问题，且是一个循序渐进的过程。

你会发现大家对于超时这一类的问题的排查套路都无外乎这样，层层递进的排查，抽丝剥茧的寻找问题。

这个案例你就是可以自己拿去用的，套一个自己工作相关的业务场景。

我就不信了，你们接口调用没出现过超时的情况？

网上这样的文章很多很多，但是作者写的只专注于面试问题的本身。

如果你想要把这个案例套过来自己用，那么而这个问题能延伸出来的东西，你也必须得去研究。

比如前面这个文章里面，为什么要说“失败策略是 failFast，快速失败不会重试”？因为如果是failover，会默认重试，且超时时间是重试时间之和。所以，他告诉我们，这里没有重试，超时不是因为请求重试带来的时间叠加导致的。

文章提到的 ElapsedFilter 过滤器，“超过 300 毫秒的接口耗时都会打印”，是作者公司自己扩展的 Filter，基于Dubbo 的 SPI 实现的，并不是 Dubbo 官方的自带功能。所以，他才额外提了一句“ElapsedFilter是 Dubbo SPI 机制的（自定义）扩展点之一”。

作者用的 Druid 连接池，猜测连接长时间不被使用后都回收了，那么关于 Druid 的配置文件中的有关时间的配置，你是否知道且清楚其作用？

如果要观察 GC 日志，你是否大概知道应该配置什么参数，是否知道应该关注的信息是什么？为什么他这里要提到安全点？安全点和 STW 的时间之间的关系又是什么？

等等后面的一些关于容器的、Arthas工具使用的、网络抓包工具使用的相关技能和知识储备。

当我们把这些知识单独拎出来形成面试题的时候，也许你会觉得，为什么你老是问我 MySQL 的知识、问我网络相关的知识、问我一些用不上的垃圾回收的知识？

问你，把你问的哑口无言不是目的。考察你知识的广度，让你学以致用才是目的。

重要的是把你学的一个个孤立的点，通过某种方式，串联起来。

而“你在工作中遇到过什么印象深刻的困难呀”就是你把这些知识点串联起来的一种方式。

除了前面的文章，我还分享这些类似的，你以为我只是单纯的给你分享吗？

不是的，我自己也在收集，也在融会贯通，也想着“拿来主义”。

除了这一篇以外，我还发过很多类似的：

一个不错的线上故障排查案例，现在它是你的了。

你在工作中有没有碰到什么比较棘手的问题？