前言：
最近发生过几次线上服务出现不能接收任何请求的情况，造成了较大的影响。该种情况一般称之为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能力下降进而造成假死。合理进行代码的处理，就可以避免和解决服务假死的问题！
