讲动手实践遇到问题不要慌轻松搞定内存泄漏海量资源.pdfVIP

本文由简悦SimpRead转码，原文地址

当一个系统在发生OOM的时候，行为可能会让你感到非常困惑。因为JVM是运行在操作系统之上的，

操作系统的一些限制，会严重影响JVM的行为。故障排查是一个综合性的技术问题，在日常工作中要增

加自己的知识广度。多总结、多思考、多记录，这才是正确的晋级方式。

现在的互联网服务，一般都做了负载均衡。如果一个实例发生了问题，不要着急去重启。万能的重启会

暂时缓解问题，但如果不保留现场，可能就错失了解决问题的根本，担心的事情还会到来。

所以，当实例发生问题的时候，第一步是，第二步才是问题排查。什么叫呢？就是的这台

机器从请求列表里摘除，比如把nginx相关的权重设成零。在微服务中，也有相应的机制，这里默

认你已经有了（面试也默认你已经有功能了）。

本的内容将涉及非常多的Linux命令，对JVM故障排查的帮助非常大，你可以逐个击破。

1.GC引起CPU飙升

我们有个线上应用，单节点在运行一段时间后，CPU的使用会飙升，一旦飙升，一般怀疑某个业务逻辑

的计算量太大，或者是触发了死循环（比如著名的HashMap高并发引起的死循环），但排查到最后其

实是GC的问题。

在Linux上，分析哪个线程引起的CPU问题，通常有一个固定的步骤。我们下面来分解这个过程，这

是面试频率极高的一个问题。

（1）使用top命令，查找到使用CPU最多的某个进程，记录它的pid。使用Shift+P快捷键可以按

CPU的使用率进行排序。

（2）再次使用top命令，加-H参数，查看某个进程中使用CPU最多的某个线程，记录线程的ID。

（3）使用printf函数，将十进制的tid转化成十六进制。

（4）使用jstack命令，查看Java进程的线程栈。

（5）使用less命令查看生成的文件，并查找刚才转化的十六进制tid，找到发生问题的线程上下文。

我们在jstack日志中找到了CPU使用最多的几个线程。

可以看到问题发生的根源，是我们的堆已经满了，但是又没有发生OOM，于是GC进程就一直在那里

回收，回收的效果又非常一般，造成CPU升高应用假死。

接下来的具体问题排查，就需要把内存dump一份下来，使用MAT等工具分析具体了（将在第12

讲解）。

2.现场保留

可以看到这个过程是繁杂而冗长的，需要很多内容。现场保留可以使用自动化方式将必要的信息保

存下来，那一般上系统会保留哪些信息呢？下面我进行一下总结。

###

2.1.瞬时态和态

为了协助我们的分析，这里创造了两个名词：瞬时态和态。瞬时态是指当时发生的、快照类型的元

素；态是指按照频率抓取的，有固定项的资源变动图。

有很多信息，比如CPU、系统内存等，瞬时态的价值就不如态来的直观一些。因为瞬时状态无法体

现一个趋势性问题（比如斜率、求导等），而这些信息的获取一般依靠系统的协作。

但对于lsof、heap等，这种没有时间序列概念的混杂信息，体积都比较大，无法进入系统产生有

用价值，就只能通过瞬时态进行分析。在这种情况下，瞬时态的价值反而更大一些。我们常见的堆快

照，就属于瞬时状态。

问题不是凭空产生的，在分析时，一般要收集系统的整体变更集合，比如代码变更、网络变更，甚至数

据量的变化。

接下来对每一项资源的获取方式进行介绍。

###

2.2.保留信息

（1）系统当前网络连接

ss-antp$DUMP_DIR/ss.dump21

其中，ss命令将系统的所有网络连接输出到ss.dump文件中。使用ss命令而不是netstat的，是

因为netstat在网络连接非常多的情况下，执行非常缓慢。

后续的处理，可通过查看各种网络连接状态的梳理，来排查TIME_WAIT或者CLOSE_WAIT，或者其他

连接过高的问题，非常有用。

线上有个系统更新