Java服务端程序“假死”怎么办？ _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 -gcutil PID 1000 #注：PID请更换为java进程号

文章插图
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命令将内存堆转储成文件进行详细的分析了。常用的命令如下：

jmap -dump:live,format=b,file=memory.hprof PID

该命令将堆转储成名为memory.hprof的文件，后续可以使用堆内存分析工具（如Eclipse Memory Analyzer）等进行详细分析，在此不再展开。
2.1.4 jstack命令
jstack是JDK提供的一个可以生成JVM当前时刻的线程快照信息的命令行工具，可以探查在命令执行那一刻JVM中每个线程都在做什么。在实际使用中，可以每隔10秒钟执行一次，连续执行几次再对比分析，实际中的输出内多会比较多，建议转存到文件中方便分析。常用的命令如下：

jstack -l PID >> stack.log #结果输出到stack.log文件中