线上异常排查总结

• 单台或个别机器突然CPU升高
  先排除网络波动，部分机器处于失效状态，流量集中在部分机器上
检查GC情况，FullGC突然增加，检查一下连接数据库连接的情况，排除sql集合过大影响。
检查定时任务，定时任务错峰执行
消息、请求堆积后恢复时的瞬时流量引起，减少消费线程

• 单台或个别机器突然LOAD升高
  锁资源争抢，代码上下文复杂度低，导致大量线程停留在上锁代码处竞争锁，使用jstack或kill -3导出所有线程调用栈，是否有较多线程停留在相同方法区
云机与docker同时伴随着ST升高，说明式宿主机的其他容器正在抢占资源
线程循环调用，查看虚拟机下的线程状态，长期运行中且较高CPU使用率的都是可疑线程，使用top -Hp等命令可以过滤出这一类线程，通过导出调用栈来确定循环位置
IO等待，检查Blocked的线程，定位代码逻辑。可以通过缓存方式单线程写入优化IO写入。
检查GC情况，如果使用了CMS，持续观察LOAD升高时的是否存在CMS并发收集情况。可优化CMS的配置，如清理阈值，内存整理等
死锁排查

• 内存使用异常
  公网机器先检查连接情况，排除大量失效连接未断开引起的问题
jstat -gcutil 命令观察启动内存负荷与GC情况，对于异常发生时，老年代上升很快，需要确定是否由PretenureSizeThreshold配置引起的，导出内存，找出大对象
检查堆外内存使用，一些缓存工具可能会使用堆外内存减少对GC的影响。netty也可以选择使用池化堆外内存。
打开GC日志，观察YGC后是否有对象晋升到老年代，评估内存泄漏可能
出现PermGen space关键字d，一般是SPRING代理过多导致了1.6版本的Perm空间溢出，检查类加载情况
空间分配不合理，引起对象过早进入Old，检查空间分配和老年代晋升配置，配合GC日志优化配置
集合频繁扩容，用map或collection通信时，多次扩容容器，产生大量内存对象，伴随CPU上涨
内存泄漏，多数发生于无界队列问题，消费缓慢导致队列无上限增加

• RT升高业务响应变慢
  1.8以下排除hash冲突引起的单链表过长的问题
消费线程池满，导致新进入的请求无法处理，扩大线程池，定位调用链路，减少调用链路中阻塞
慢查询、数据库死锁引起连接池满，大量请求堆积。查看日志、数据库慢查询日志与数据库当前连接情况，是否存在上述情况
排除缓存击穿情况，验证数据库访问量是否上升

• 吞吐量下降、SI过高
  检查核心中断情况，是否大量中断都集中在个别CPU上
内核信息获取会有内核锁，部分监控会读取内核信息从而导致软中断抖动，观察进程与SI之间变化可找到影响

• 间歇性无法启动或异常重启后出现(消失)
  类冲突、找不到方法的异常多数是JAR包冲突引起的，或MAVEN中低版本的代替了高版本引起的。通过日志定位异常类，使用工具找到冲突包，如arthas等即可轻松解决

• 慢查询(MYSQL)
  伴随limit与order by往往是全量扫描，全量扫描附加条件往往无法命中索引，建议使用主键排序，后根据前一次的最大最小主键id再次约束范围，其他条件语句将会被优化到排序后。