标签：
现象： 当前项目启动一段时间，有一个服务导致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，问题解决。
标签：
原文地址：http://www.cnblogs.com/lingdubingchuan/p/5741302.html
