一次服务器CPU占用率高的定位分析

现象： 当前项目启动一段时间，有一个服务致使CPU使用率持续超过30%

环境：Windows 7,  CPU: 8核， 内存: 8g内存

 

定位过程：

启动项目，查看Java进程ID

 

查看Event Processor 的CPU使用状况，此时基本维持在1%左右：

 

开启Simulator发送几包数据，再次查看，发现CPU已经飚上去了：

 

关闭Simulator，等待数据都处理完毕，再次查看，CPU并未降下去：

 

使用ProcessExplorer查看Event Processor线程的CPU使用状况，发现线程40160和40156的CPU占用率持续很高，

 

使用jstack -l 35684 打印出Event Process的线程栈，查看线程ID(需转化成16进制)对应(40160-> 9CE0, 40156-> 9CDC)的线程栈：

 

能够看出，线程TaskScheduler_com.delta.atm.services.impl.AutoTTExecutorServiceImpl和TaskScheduler_com.delta.atm.services.impl.AlarmExecutorServiceImpl处于运行状态，持续打印线程信息发现这两个线程一直处于RUNNABLE的状态，此时并未开启simulator，此线程应该处于睡眠才对。

 

先走读代码，查看AlarmServiceImpl,

再查看SchedulerServiceImpl,

 

从下面代码的角度看，在没有数据的状况下takeTask应该只会执行一次，而后休眠，等待唤醒。

 

根据打印的线程栈发现，这两个线程都长时间运行在takeTask方法，因此猜想这个部分有死循环，并且因为此机器是8核，1/8=0.125，若是有两个线程持续While循环，则基本就会占用25%的CPU资源。

 

加上输出，打印出全局的count，找到缘由了，线程睡眠的条件是count为0才睡眠，可是数据都处理完了打印出来的count不为0因此线程会一直空转，

 

可是为何会出现数据处理完count还不为0的状况呢？

 

从代码结果来看alarmService每收到一包数据count就会加1，每取一包数据，count就会减1，并且count是AtomicInteger线程安全类型。

因为alarmService用的是一个生产者-消费者模型，大概结构以下图所示，须要一个全局的count来表示全部queue里面的数据，当count数量为0的时候Task Schedule则睡眠，不然会持续调度。

 

 

查看当前queue里面的数据是空的，说明queue里面的数据已经处理完了，可是count的值却不是0。

查看下面的代码找到缘由，这个queue是咱们本身封装的，每一个site对应一个queue，key值是dataTime，这个值是根据印度的box取的且只有10位，精确到秒，可是simulator每一个站点数据的发送频率常常会一秒钟发送多包数据，因此就会有重复的dataTime，也就形成了queue里面数据被覆盖了，这个时候queue的总大小就和记录的count不匹配了。

 

其实这个queue的内部咱们使用的是一个treeMap，因此不容许key值重复，最好的办法是重写一个容许key值重复而且可排序的一个队列，可是考虑到现实环境中每一个站点3分钟才发一包数据不可能出现每秒多包数据的状况，并且TreeMap内部用的是红黑树效率挺高的，若是本身写排序算法效率可能不会太好，因此暂时使用判断作规避，若是同一个站点queue里面已经有相同的dataTime则直接忽略这一包数据。

 

从新打包启动查看输出， count已经降下来了

 

查看CPU使用率以下

 

查看线程状态，已经处于waiting，问题解决。