问题描述

在工作中经常遇到tomcat占用cpu居高不下，top显示结果超过200%，请求无法响应，针对这种情况有以下处理办法进行排查。请求无法响应。


问题排查

1、获取进程信息

通过jdk提供的jps命令可以快速查出jvm进程

jps pid

2、查看jstack信息

jstack pid


3、将十进制pid转换为16进制

将十进制转换成16进制
# printf "%x\n" 19713-->将第2步查到占用较高CPU的线程号转换为16进制，以便于jstack查看
4d01

#jstack pid | grep 0x4d01--> 0x4d01为第3步19713转换为16进制后的数字，因为jstack显示的线程号是以16进制表示的！

将16进制转换成十进制
# printf "%d\n" 0x4d19

jstack的作用是显示正在运行的所有java线程情况，jstack pid | grep 0x4d01的意思只显示某个java线程的运行信息。通过这种方法，可以将此线程正在运行的方法显示出来，将此方法交给开发即可。（也可能jstack pid | grep 0x4d01什么都没有出来的）


4、打印线程的堆栈信息

jstack pid | grep tid -A 30

此处不一一列表各tid的堆栈信息了，在其中一个的tid堆栈信息中找到了问题的原因


5、进一步排查，分析每个线程的cpu占用量

简单点儿的方法则是，查出进程id后，通过如下命令查看该进程中每个线程的资源使用情况

top -H -p pid   -H用于显示某个进程的所有线程

从这里获取pid（线程id），转换为16进制，然后去stack信息中查找对象的线程信息。

通过上述方法，查出tomcat进程对应的线程cpu占用率累积之和约80%，远小于top给出的200%+

说明并不存在长期占用cpu的线程，应该是属于有许多短暂性的cpu密集计算。进而怀疑是不是jvm内存不足，频繁gc导致。

jstat -gc pid

发现jvm内存使用并未出现异常，gc次数明显暴涨

查完内存，由于本身是一个网络程序，进一步排查网络连接。


6、问题定位

查询tomcat对应端口的tcp链接，查看是否存在大量EASTABLISH的链接，或还有部分其它状态的连接。

netstat -anlp | grep port


netstat状态说明：

LISTEN：侦听来自远方的TCP端口的连接请求
SYN-SENT：再发送连接请求后等待匹配的连接请求（如果有大量这样的状态包，检查是否中招了）
SYN-RECEIVED：再收到和发送一个连接请求后等待对方对连接请求的确认（如有大量此状态，估计被flood***了）
ESTABLISHED：代表一个打开的连接
FIN-WAIT-1：等待远程TCP连接中断请求，或先前的连接中断请求的确认
FIN-WAIT-2：从远程TCP等待连接中断请求
CLOSE-WAIT：等待从本地用户发来的连接中断请求
CLOSING：等待远程TCP对连接中断的确认
LAST-ACK：等待原来的发向远程TCP的连接中断请求的确认（不是什么好东西，此项出现，检查是否被***）
TIME-WAIT：等待足够的时间以确保远程TCP接收到连接中断请求的确认
CLOSED：没有任何连接状态