这两天客户这边有一台服务器一到下午3点左右就开始卡住，页面无法访问，服务器CPU占用达到300%多
开始以为只是可能只是意外事件，重启一下就好，但是发现重启之后没几分钟服务器马上又反应无法访问，我就开始检查自己写的代码是不是有什么非常消耗CPU资源的逻辑，但是找了一段时间之后还是一无所获，不过马上反应的就是先把最新提交发布的代码还原到上一个版本。但是没过多久还是反应服务器开始又开始无法访问了。 于是就 第一步: 通过 top命令查找到这个消耗CPU的进程号PID 8958
top 第二步：使用
top -Hp pid（
shift+p 按cpu排序，shift+m 按内存排序
）
top -Hp 8958
获取到这个进程下面所有线程，通过查看%CPU找到最耗费CPU的是线程PID

第三步：使用
printf ‘%x\n’ PID (PID为上一步中获取到的线程号)转换成对应的16进制PID 5c7e

第四步：使用jstack 获取对应的线程信息 jstack 8958 | grep 5c7e 注意：8958是一开始获取的进程号,而5c7e则是这个进程下面最最耗费CPU的线程号

根据上图我们可以看到名叫GC task thread#2 (ParallelGC)就是这个线程消耗了大量的CPU。这个线程是一个垃圾回收线程，垃圾回收线程大量占用CPU 说明我们的JVM内存被消耗得很快，导致垃圾回收器不断地回收内存而消耗CPU，而内存消耗的很快就跟我们的代码有关系，说明我们的代码创建了大量的对象或者执行了其他消耗内存的操作，这需要检查这个时期的其他线程在做一些什么工作而导致消耗了大量的内存
第五步：jstack pid(进程pid)>stack.dump

执行上面的命令，将该消耗进程的线程相关信息导出到stack.dump文件中，打开这个文件查看每个线程的具体状态
一般来说，出现问题的代码大多数是我们自己写的业务代码导致的，所以我们可以通过查看那些我们自己创建的类的相关信息，比如根据我们自己创建的包路径去搜索，搜索结果可能不止一个地方会出现我们的包路径，这个就需要结合我们自己的代码的业务逻辑来定位到底是哪一个线程可能出现问题了。

下面是这次我遇到的问题例子：

像我遇到的这个问题，这一个正在执行的线程是一个用户上传导入Excel的操作，而这个用户导入的Excel中每行有非常多的多余的空白列他没有删除，而且又有非常多的多余的空白行，而我们的代码是需要去读取每行的每一列，这就导致代码创建了大量的对象，最后使得内存被消耗完，然后垃圾回收线程就开始不断地占用CPU回收内存了。

当然实际情况中还包括其他的一些原因状态导致的，比如说死锁，这都需要具体去分析导出的信息。

参考：https://blog.csdn.net/zxh87/article/details/52137335#!/_z838w71pwcr