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上进行实时监控。这时赶紧调用netstat -anp|grep 9097命令查看一下当前是否有请求，发现zabbix那边的请求全部卡死了。

这些卡死的请求全部都在ESTABLISHED状态，基本上把tomcat的socket连接全部占满了，这下终于明白为啥调用查询接口，服务没有响应了，但是为什么这些查询接口会卡死呢？

3、查看JVM基本信息

　　想要弄明白这个问题，还是要查看一下JVM内部的信息，是否内存溢出或者CPU占满，这里采用arthas插件，下载arthas后就可以通过java -jar arthas-boot.jar直接启动。

该服务是第一个，选择1按enter键进入

通过dashboard命令查看服务运行的基本信息

　　从上图可以看出，CPU占用率不是很高，但是内存占用率比较高，特别是老年代，该服务总共分配了20G的内存，新生代10G，老年代10G 。服务启动不久后就进行了Full GC，很快老年代就被占满，这说明有很多大对象在内存中，并且没有被Minor GC回收掉，进入了老年代。

4、查看GC日志

　　为了验证我的猜想，通过jstat -gcutil221446 1s命令每隔1s将GC信息实时打印出来，如下图所示。

　　E表示Eden区的内存占用率，O表示老年代的内存占用率，YGC表示年轻代GC的次数，YGCT表示年轻代GC的时间总和，FGC表示Full GC的次数，FGCT表示Ful GC的时间总和。从上图可以看出，在195次Full GC后，Eden区仅仅过了4秒内存就基本上满了，这时又发生了Full GC，即第196次Full GC。

目录