记一次CPU有规律飙高的线上问题排查过程
一、背景
最近在计费系统模块和灰度发布相关的功能已经基本交付，在这个间隙中，领导说有个线上问题需要排查下，
问题的场景比较有意思，排查过程中也有一些成长，这里记录一下。
二、排查过程
2.1 查看pinpoint 监控
首先根据领导的反馈看pinpoint中的JVM的CPU日志：
CPU每隔一个小时会有一个突刺，对于平时的表现来看有个波峰。而且通过不同时段的波峰的表现看是相对有规律的，同时波峰的持续时间也是不太固定的，有时候是2-4分钟，有时候是将近10分钟，另外发生波峰的时间点大多在每个小时的前10分钟左右，如下监控显示：
2.2 排除FGC的影响
因为最近上线该服务的时候我们修改了JVM的启动参数，领导说可以明确没有GC，这里我也看了JVM的启动参数：
另外就是堆内存和非堆内存的监控也没有明确有GC的影子，所以这里先排除FGC的影响。另外一方面如果出现CPU利用率飙高的情况下之前遇到的都是接近百分之百，目前基本是75%左右。
2.3 查看ELK日志-SQL部分
这里先看一下该服务在处于CPU飙高的时间段内SQL方面的监控日志：
排查如下日志：
[cn.xxx.dao.xxMapper.selectByxxxIdAndRound]-[debug]:<== Total: 1
这里主要看SQL内容和Total字段返回的条数，但是基本上没有发现问题，可以排除是SQL 方面的原因了。
2.4 查看缓存代码
由于之前做过分布式本地缓存刷新的方案和落地，所以就敏感的去查一下本地缓存方面的代码，因为有个关键点是本地缓存用Guava构建的，同时注释说明是每个小时构建一次，这里我们看一下构建代码：
CacheLoader<String, Map<String, Object>> loader =new CacheLoader<String, Map<String, Object>>() {@Overridepublic Map<String, Object> load(String key) throws Exception {return loadInfo(key);}@Overridepublic ListenableFuture<Map<String, Object>> reload(final String key, Map<String, Object> voiceSiteInfo) {ListenableFutureTask<Map<String, Object>> task =ListenableFutureTask.create(new