Java服务端程序“假死”怎么办？

Labs 导读

作为Java开发者，在日常工作中经常会碰到Java服务端程序无法响应客户端的请求，轻则影响用户体验，重则会造成重大故障。这种无法响应客户端的请求就是常说的服务“假死”、“卡住了”。那么，在这种“假死”的背后到底发生了什么事，本该正常响应客户端请求的进程、线程又在做什么呢？本文带你来揭晓这一答案。

Part 01、 程序“假死”的迹象  

服务端程序卡死之后，最常见的现象是无法响应客户端请求，结果返回特别慢直至超时。如果是网页服务，那么用户会发现该页面会无法访问，或者一直加载不出来。

如果此时深入查看Http协议，其返回状态码一般是504（Gateway

Timeout），提示网关超时。如果该程序对应的进程还在存活在操作系统中，在排除了网络、服务器问题后，可以认为该程序已经“假死”，无法再继续提供服务。有些程序在假死后过一段时间可以自己恢复，然而更多的时候需要人工介入重启程序才能恢复正常。

Part 02、如何定位假死问题 

接下来我们看一下当碰到程序假死问题时，应该从哪些方面着手处理，如何快速定位到根本原因。

2.1 常用的工具

工欲善其事必先利其器，我们首先来看下一些常用的诊断问题的工具。

2.1.1 top命令

top命令是Linux下常用的性能分析工具，能够实时显示系统中各个进程的资源占用状况，操作系统自带。在终端中输入top即可看到正在运行的所有进程占用的CPU、内存、运行时间等，也能够大致知晓当前服务器的运行状态。

top命令结果

以上是一张典型的top命令结果图，可以看出java进程进行占用了 44.7%的内存，118.8%的CPU（多核的CPU使用率会超过100%），但系统1分钟的平均负载（load average）只有0.92，运行较为稳定。

2.1.2 jstat命令

jstat 是用于监控虚拟机各种运行状态信息的命令行工具，包括了对Heap size和垃圾回收状况的监控，由JDK提供。当需要了解JVM的运行状态时它是首选工具。比如需要每秒查看一次JVM的垃圾回收状态，可以使用：

jstat命令结果

上图是进程号为4417的JVM进程的内存使用情况，S0和S1是新生代中幸存区使用比例，E是伊甸园区空间使用比例，O是老年代空间使用比例；YGC是新生代垃圾回收次数，YGCT是新生代垃圾回收总时间；FGC是老年代垃圾回收次数，FGCT是老年代垃圾回收总时间，GCT是垃圾回收总时间。当出现内存不够用时，O会出现100%，并且FGC和FGCT持续增加，比较容易辨别。

2.1.3 jmap命令

jmap是JDK提供的一个可以生成JVM的堆转储快照dump文件的命令行工具。除此以外，jmap命令还可以查看finalize执行队列、Java堆和方法区的详细信息，比如空间使用率、当前使用的什么垃圾回收器、分代情况等等。当出现内存问题时，就需要jmap命令将内存堆转储成文件进行详细的分析了。常用的命令如下：

该命令将堆转储成名为memory.hprof的文件，后续可以使用堆内存分析工具（如Eclipse Memory Analyzer）等进行详细分析，在此不再展开。

2.1.4 jstack命令

jstack是JDK提供的一个可以生成JVM当前时刻的线程快照信息的命令行工具，可以探查在命令执行那一刻JVM中每个线程都在做什么。在实际使用中，可以每隔10秒钟执行一次，连续执行几次再对比分析，实际中的输出内多会比较多，建议转存到文件中方便分析。常用的命令如下：

jstack命令部分结果

上图是jstack命令的部分结果，显示名为logback-8的线程此刻正在等待状态，未执行实际的任务。

2.2 诊断三把斧

JVM进程假死其实就是线程不够用了，忙不过来，用以下三把斧依次施行，基本上能够覆盖90%以上场景。

2.2.1 看进程

首先，使用top命令对服务器的负载和进程的资源使用做一个评估。尤其关注top命令中的负载指标和进程的CPU、内存使用率。负载代表服务器的繁忙程度，它综合了CPU、IO等指标，负载/CPU数
> 1
代表服务器非常繁忙。当系统负载高时，而每一个进程的CPU都不高时，要考虑服务器是否已经过载，比如运行进程过多、IO瓶颈等。当某个进程的CPU使用高时，问题大概率出在该进程中，即可对该进程进行探查。（本文只讨论JVM，故进程特指JVM进程）

2.2.2 看内存

使用jstat命令查看JVM的内存状态。当JVM内存泄漏导致堆内存无法回收、堆内存不够用从而触发频繁的Full
GC时，JVM会停顿程序的执行进行全面的垃圾回收（stop the
world），此时程序将无法响应请求，GC线程会占用大量的CPU时间。当这种情况发生时，会出现进程CPU使用率很高，接近系统极限。堆内存中老年代空间使用比例接近或达到100%，FGC、FGCT在持续地上升（正常情况下Full
GC几小时甚至几天才执行一次）。

当判断为进程因内存问题而一直在Full

GC时，可以使用jmap命令将内存dump下来进行进一步的分析，查找内存泄漏的对象，进而进一步找到内存泄漏点。此外，值得注意的一点是如果堆内存本身设得很小，而程序需要的内存又很多，JVM会尝试去回收内存，也会出现频繁的Full
GC而导致CPU使用率升高的情况。这就需要具体问题具体分析了。

2.2.3 看线程

使用jstack命令查看线程状态。当操作系统、堆内存都无明显异常情况下，需要进一步探查每一个线程都在做什么。线程无法处理更多任务，要么是线程都很忙（单核
CPU 100%），要么是都在等待（CPU使用率不高），极少数是处于死锁状态，而这些都可以从jstack的命令结果中看出来。

jstack会显示每个线程当前所处的程序栈。如果多个线程处在同一个程序栈，那么要引起高度注意，可以通过连续几个间隔10秒左右的jstack结果查看该线程是否一直处于同一位置，如果是那么大概率是卡在了这里。如果是死循环，那么CPU使用率会很高，如果是等待IO，那么CPU使用率会很低。通过卡住的程序栈，可以较容易定位到代码行并进行进一步的分析了。

Part 03、 案例实战 

了解完基本的理论知识，下面通过实际工作中碰到的案例来使用三把斧进行分析。

3.1 案例一：IO等待

系统表现：界面无响应，请求API也无响应。

看进程：top命令显示系统负载很低，进程CPU、内存使用也无异常。

看内存：jstat命令显示堆内存表现正常：

jstat显示堆内存状态正常

看线程：jstack命令显示绝大部分线程都卡在同一个地方：

出现io等待的线程

通过进一步检查AbstractProvinceServiceImpl.sendPost方法，发现是使用java原生的HttpUrlConnection来实现Http请求的方法，而该方法未设置超时时间，如果被调用方未返回会一直等待。

有缺陷的代码

至此，问题原因查明：因代码缺陷，在发起http请求时未设置超时时间，而恰好此时被调用方系统故障，无法及时返回，从而导致线程都卡在这里等待IO，无更多的线程来响应其他请求了。

3.2 案例二：死循环

系统表现：系统响应很慢，api请求有一定的错误率。

看进程：top命令显示系统负载较高（1核CPU），进程CPU达到190%，系统过载。

负载较高，进程CPU使用率较高

看内存：jstat命令显示堆内存表现正常，无明显的内存问题。

看线程：多次间隔执行jstack命令，发现一部分进程一直卡在同一个地方：

出现死循环的线程

通过查看相关代码发现这里有个死循环，当变量cur一直不为null时，程序无法跳出循环。通过更进一步的分析，最终找数据库中的一条数据其CateParentId是自己，从而触发这个死循环的bug。

...


while (Objects.nonNull(cur)) { 
    allCateName.insert(0, "/"); 
    allCateName.insert(0, cur.getCateName()); 
    cur = goodsCatePOMap.get(cur.getCateParentId()); 
} 


...

Part 04、  总结 

对于Java服务端假死，可以通过本文介绍的三把斧，利用一些常用工具来对程序内部的运行状态进行分析。掌握这个方法后，基本上可以定位到工作中碰到的90%以上的java程序假死问题。下表是对可能的假死原因做一个简单的归纳总结：