记一次生产事故的排查与优化——Java服务假死

一、现象

在服务器上通过curl命令调用一个Java服务的查询接口，半天没有任何响应。关于该服务的基本功能如下：

1、该服务是一个后台刷新指示器的服务，即该服务会将用户需要的指示器数据提前计算好，放入redis中，当用户请求指示器数据时便从redis中获取；

2、指示器涉及到的模型数据更新时会发送消息到kafka，该服务监听kafka消息，收到消息后触发指示器刷新任务；

3、对于一些特殊的指示器，其涉及的项目和模型较多，且数据量比较大，无法通过kafka消息来触发刷新，否则一直处于刷新过程中，便每隔10分钟定时进行指示器的刷新，以尽量保证的数据的及时性；

4、该服务不对外提供接口，只预留一些指示器刷新的监控接口，供内部开发人员使用；

5、相同代码还部署了另外一个服务对外开放，用户请求指示器数据时就向其请求，如果redis缓存中有便直接返回，没有的话那个服务便实时计算。

二、排查

1 、打印堆栈

看到上述的现象，第一反应就是服务挂了，于是便通过 jps 命令查看该服务的进程号，发现服务还在。 那么会不会是tomcat的线程被占满，没有线程去响应请求，但是按理说是不会的，因为该服务并没有对外提供接口。 抱着好奇心还是通过 jstack pid 命令打印出堆栈来查看，如下图所示。发现当前只有10个tomcat的线程，并且都处于空闲状态，那么就不可能因为线程被占满而导致curl接口没有响应。

2 、查看socket连接

就在一筹莫展之时，同事告诉我zabbix监控那边会每隔一分钟调用该服务的查询接口来获取当前的刷新任务数，从而展示在zabbix上进行实时监控。 这时赶紧调用