一次CPU突然飙高的详细排查流程

1、问题描述

有一天有个同事突然找来和我说，你最近是不是上什么代码，现在部署订单项目（临时起的名字，具体项目于不变透漏）似乎线程夯住了，所以请求都超时了。快看看和你有没有关系。吓的我一头冷汗，赶快排查走起。然后直接看服务器。

2、解决方案：

2.1 使用top命令一查看，好家伙，有个进程直接占满CPU。

​2.2 使用top -Hp 1查看线程，看到线程号为13的占满了CPU。对应的16进制是D。

​2.3 到这时我觉得一切都挺顺利的，但是意外还是发生了。我使用命令 jstack 1 |grep -A 5 0xd。查看对应的RUNNABLE，想看看是哪个类导致线程占满了。结果没有找到。我这个郁闷哈。后来我不相信，又仔细的查看，所有 RUNNABLE的线程，对应只能看到好像和MQ和JSON有关。这里由于匆忙没有截取对应的图片。

​2.4 又换了一招，使用jmap -histo 1|head -20,这时候可以看到里面有个占用很大的对应。

​2.5 接下来怎么走就值得思考。因为这个对象引用的地方很多。因为最近没有上新的代码，所以大概能够应该是偶发的的情况。所以我们又好好看启动的日志。最后发现了端倪。每次启动到消费这条MQ的时候，真个启动服务基本上就卡住了。

​2.6 所以我们顺着代码直接查找，最后发现了问题。

​2.7 我们先把这条消息直接从Rocketmq中删除了，然后暂时保存起来。让系统先恢复正常运行。

到这时终于可以松一口气了，不是自己的问题，哈哈。所以后续通知业务排序看看这个值到底是怎么回事。合不合理。

3、问题思考

在2.4里面没有直接找到对应的分支。我猜测可能是因为图中的写法，采用的策略设计模式方案导致，不能直接定位到具体的线程，直接搜索RUUNABLE大概可以看到因为2.6的原因。(有待验证)

​总之大家遇到问题CPU飙高的问题不要慌，按照上面的方法，基本不会存在太大的问题。