CPU占用高系统反应慢之问题定位
今天遇到测试服务器比较卡，调用调用超时，响应很慢，成功率低的问题，然后想着去处理这个问题。
本着开发的精神，摒弃网管的水平，寻找问题的根源。
主要从如下几个方面入手：
1：查询服务器硬件等情况（一般不会）
2：查看网络是否正常，是否因为网络的原因导致服务器缓慢，是否nginx/apache类的代理原因。
3：查询服务器日志是否正常，如果是Tomcat，则看下容器日志是否正常，应用日志是否正常等
4：查询服务器是否正常，本文讲述的是服务器查看方面的情况
排查方法：
一： top命令查询哪些进程导致了服务器处理器及内存使用情况
top命令是Linux下常用的性能分析工具，能够实时显示系统中各个进程的资源占用状况，类似于Windows的任务管理器。
top是一个动态显示过程,即可以通过用户按键来不断刷新当前状态.如果在前台执行该命令,它将独占前台,直到用户终止该程序为止.
比较准确的说,top命令提供了实时的对系统处理器的状态监视.它将显示系统中CPU最“敏感”的任务列表.该命令可以按CPU使用.内存使用和执行时间对任务进行排序；
而且该命令的很多特性都可以通过交互式命令或者在个人定制文件中进行设定。
一：执行命令，查询哪些进程导致了服务器CPU高或者内存高等问题（下图只是写博客的时候，从服务器中截图，非实时排查的时候的图，图仅供参考）
查询过程中，可以通过此命令，排查是CPU高还是内存高。
如果是CPU高，则看对应的CPU高的进程问题的线程列表。
如果是内存使用高，则看对应内存高的进程的线程列表，定位问题。
top
二：使用top -Hp pid查询具体的进程中的线程使用情况（本次主要讲解CPU的问题）
假使上图中的PID为529的JAVA进程占用CPU 比较高，那么我们就需要查询下这个进程下哪个线程占用了高。
可以通过命令top -Hp 529来查询线程列表，列表如下
假如上图中，看到859的线程占用的CPU很高，那么可以看到 PID是 529 ，CPU使用率，内存使用率等
使用在线工具，直接转换 859 转换 为35b 在线进制转换工具
三：杀JavaCore找出对应的线程信息
获取javacore和heapdump文件的方法有两种：
第一种：
系统发生内存溢出，在目录下会生产javacore和heapdump文件生成（最常见的一种）
第二种：
手动触发生成javacore和heapdump文件
kill -3 859
在某些系统中，可以使用kill -3 来杀进程(部分系统或者容器不支持)，获取到JavaCore线程信息，或者使用jstack来获取。
当时的主要发现mysql有较多的locked,所以试着查询资料及继续分析，具体资料如下
at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:150) at java.net.SocketInputStream.read(SocketInputStream.java:121) at com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:114) at com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:161) at com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:189) - locked <0x00000000a1c98270> (a com.mysql.jdbc.util.ReadAheadInputStream) at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:3036) at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3489) at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3478) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4019) at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2490) at com.mysql.jdbc.ServerPreparedStatement.serverExecute(ServerPreparedStatement.java:1398) - locked <0x00000000a1c753c0> (a com.mysql.jdbc.JDBC4Connection) at com.mysql.jdbc.ServerPreparedStatement.executeInternal(ServerPreparedStatement.java:856) - locked <0x00000000a1c753c0> (a com.mysql.jdbc.JDBC4Connection) at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:2322) - locked <0x00000000a1c753c0> (a com.mysql.jdbc.JDBC4Connection)
四：根据生成的信息，分析CPU使用情况
查询资料及分析当时的情况
分析如下：
1：当时的环境，出现慢SQL的情况，定位发现，查询时间过长，发现SQL触发了性能安全机制，自动加入黑名单中，且数据库线程被自动杀死
2：通过网上的资料原因可能是操作系统bug。
3：解决方案：上网查询相关资料，增加数据库的链接时间，试着增加链接超时时间及stocket时间，进行测试
