记录一次CPU占用过高的排查解决过程

       最近部署在阿里云的项目总是无故被kill，并且登录到阿里云服务器查看的时候，发现卡的不行，怀疑可能cpu占用过高，就排查了一下，将排查过程进行记录。

1、先用top查看占用cpu较高的进程id(PID)

可以发现进程id为14073的进程一直占用98%的CPU 

2、查看该进程中线程详细情况，ps -mp 进程ID -o THREAD,tid,time

tid：线程id，time：该线程已经运行的时间 

可以发现，线程id为14181的线程CPU占有率比较高，而且运行了24分钟。

3、将tid转换成16进制的，等会可以在线程14073中通过转换后的数字查找该线程的详细信息

4、使用jstack 进程id|grep tid转换成16进制后的数字，查看该线程是否改在运行，可以看出该线程一会处于运行状态，一会处于waiting或者time_waiting状态。 

 5、使用jstack pid，查看该进程中线程的详细信息，可以看到有的时候3765处于RUNNABLE状态，有的时候处于TIME_WAITING状态，我们需要查看的是处于运行状态的详细信息，这样才能分析。

还可以使用jstack -l pid >> xxx.dump生成线程的快照信息，然后用visualVM进行分析。

 6、根据提示可以看到，占用CPU较高的是ContainerBackgroundProcessor线程，经查询，该线程是tomcat容器的后台线程(ContainerBackgroundProcessor)，根据页面的提示，我猜测是tomcat加载资源的问题。因为这个tomcat是我从其它地方直接拷贝过来的，我就怀疑是拷贝的时候里面遗留别的项目的lib，所以启动项目时也会加载那些额外的资源。因此，我重新下载一个tomcat，然后安装，打包，启动。发现cpu果然降下来了。

可以看到新安装的tomcat的其进程占用CPU较低，已经降下来了。 

注：如果碰到运行jstack以后提示Unable to open socket file: target process not responding or HotSpot VM not loaded那就可能是你程序运行的用户和你当前的用户不是一个用户导致无法访问，可切换至启动该线程的用户然后再运行jstack即可

原因分析：
jvm运行时会生成一个目录hsperfdata_$USER($USER是启动java进程的用户)，在linux中默认是/tmp。目录下会有些pid文件，存放jvm进程信息。

jps、jstack等工具读取/tmp/hsperfdata_$USER下的pid文件获取连接信息。