一次排查java占用cpu过高问题

 

近几天现场报故障过来，说A系统（java b/s应用，有较多后台线程处理任务）在现网占用系统资源非常严重，而服务器相对也比较强劲，8核CPU，16G内存，相对于我们的应用从硬件来说远远足够。

首先，top命令看一下情况，果然名为java的进程，时不时占到500%甚至700%的cpu，mpstat -P ALL 1 ，看了一会cpu情况，8个cpu(核）也基本都没闲的时候，看来问题比较严重了。我ssh到服务器敲些命令反应也不如之前快。

排查步骤：

一、使用之前的top或者jdk自带的jps，找到这个java进程的PID，假设为 2370.

二、继续使用top命令，但这次是看这个进程包含的线程cpu使用情况，命令：top -H -P 2370 -d 1 -n3>javaTop.log，这样就把这个java进程包含的线程资源使用情况重定向到文件了，-d 1表示1秒刷新一次，且加上它才能重定向到文件 。-n 3 表示采样3次。

结果大概是这样：

 

其中可以看到这些线程的cpu占用都不太正常，当然这里要注意前面的PID，这个有用。

三、使用kill -3 2370 赶紧做次threadDump，看java线程栈情况，当然也可以自己写个脚本连续间隔着做几次，这样更好排除问题。做完threadDump后，把它们复制出来，可以直接用文本工具分析，大概像这样：

图中与公司信息相关的包名已经抹掉了。图中的nid，是根据第二步的top中的PID转换为16进制后，查到的。

四、其实就是第3图中定位方法。在第二步获取的结果中，找几个PID，都转换为16进制，然后到第三步的threadDump中查找，它对应的是threadDump中的nid，多查几个更能准确说明问题。像我这定位下来，就是第三步图中的结果，即我们去获取某个目录下的文件目录个数消耗了较多的CPU。

五、这里就是根据第四步分析的threadDump，看那个类的哪行代码是在做什么事。我们这就是IO操作，去计算某个目录下文件个数。我叫现场人员看了下那个目录，有几万个文件，而我们的代码又是个递归的判断，在这里性能非常低下，并导致CPU占用奇高无比。

六、其实没什么好说的，定位了问题，就分析下如何解决了。