前言：

最近发生过几次线上服务出现不能接收任何请求的情况，造成了较大的影响。该种情况一般称之为Tomcat假死，在发生的几次中进行排查也总结了一些经验。

---

背景描述：

项目在运行过程中，突然无法处理新的请求。原来的tps都是几千几万，突然间所有机器都变为0了，对线上业务影响极大！于是立即查看服务运行状况，但是还是在running中，于是可以认为是tomcat假死。

---

Tomcat假死排查思路讲解：

造成tomcat无法继续进行业务处理的情况有很多，所以需要多方面的进行一一排查。
1.首先检查服务运行情况，判定业务无法处理的表面原因，是否为tomcat假死。
2.查看项目日志，排查是否有明显的错误情况，针对错误情况处理。
3.若项目本身无法判断问题所在，则需要对服务所在机器的网络、磁盘、CPU等进行逐一排查。
4.针对tomcat假死情况，基本由于网络上的阻塞造成的，所以优先考虑查看网络情况。
5.首先，确定请求入口是否正常，排除外部原因。
6.第二步，查看服务对应的端口的情况。使用命令netstat -anp ｜grep 端口号，可以查看该端口详细的情况，如下，有协议类型、源ip+port、tcp协议状态等信息，这里主要关注tcp协议的连接数量和每条连接对应的状态。

 netstat -an |grep 80  
tcp4       0      0  192.168.31.24.51380    120.253.255.102.443    ESTABLISHED
tcp4       0      0  192.168.31.24.50935    192.30.71.80.443       ESTABLISHED
tcp4      31      0  192.168.31.24.50863    3.80.20.154.443        CLOSE_WAIT 
tcp6       0      0  fe80::b7ca:330b:.1028  fe80::5059:ee74:.1025  ESTABLISHED
tcp6       0      0  fe80::b7ca:330b:.1024  fe80::5059:ee74:.1024  ESTABLISHED

还可以通过grep具体的tcp状态码来确定当前tcp端口的连接数量及情况。

netstat -an |grep 80 |grep CLOSE_WAIT
tcp4      31      0  192.168.31.24.50863    3.80.20.154.443        CLOSE_WAIT 
tcp4      31      0  192.168.31.24.50855    3.80.20.154.443        CLOSE_WAIT 
tcp4      31      0  192.168.31.24.50854    3.80.20.154.443        CLOSE_WAIT 
tcp4      31      0  192.168.31.24.50853    3.80.20.154.443        CLOSE_WAIT 
tcp4      31      0  192.168.31.24.50852    3.80.20.154.443        CLOSE_WAIT

除此之外，还可以使用 ss -lnr |grep 80，确定对应端口的Send-Q和Recv-Q数量。一样可以反应对应端口的tcp是否阻塞。
7.第三步，根据上一步查看服务端口的tcp情况，确定最终问题是由于tcp连接没有正确释放，导致端口的TCP连接队列打满，后续请求无法进入连接队列而造成Tomcat假死！
8.最后，确定问题后，去服务中寻找原因。可能由于对应的http请求没有进行Response，或者由于服务处理速度远不及请求的数量，导致连接队列在运行中慢慢被打满。

---

解决方案：

1.碰到该类情况，首先可以尝试进行服务的重启，可能可以继续支持服务，一定时间后服务会进入假死；同时在业务前侧进行关闭，减少甚至关闭请求量。使业务的损失降低到最小。
2.回退版本，一般问题的出现都是由新业务上线造成的，先回退无问题版本。
3.针对排查的问题，锁定问题原因，进行针对性解决。

---

总结：

造成服务假死的现象，基本是由于网络问题。多半是程序中的响应处理异常，或者在高tps系统中使用了耗时的同步操作，导致tps能力下降进而造成假死。合理进行代码的处理，就可以避免和解决服务假死的问题！