结论

本次事故没有找到原因，仅记录排查过程。（所以先出结论）

事故描述

线上N台服务器，啥也没动，其中一台突然报警，大量接口超时。

日常操作，第一个先把nginx停了，停止对外服务～剩下的慢慢看。
top命令查看进程情况。发现java进程内存使用正常，CPU使用率暴增，浮动区间200%～600%（8核）。
$ jstat -gcutile <pid> 1000 100 打印java进程的GC情况，发现YGCT是其他正常机器的3倍。
$ top -Hp <pid> 查看java进程的线程使用情况，找了CPU占用率最高的几个，记录它们的id。
$ printf “%x\n” 转成十六进制，记录。
$ jstack <pid> > jstack.log 打印进程堆栈信息，查找刚才记录的几个所在的线程，CPU占用率最高的是GC线程，不管。有一个BLOCKED状态的线程，是MQClient，其中报错为MySQL连接失败，但是检查了MySQL配置，可以ping通，怀疑CPU过高导致TCP连接超时。另外占用高的有NettyClientWorkerThread，MQ-AsyncArrayDispatcher-Thread等等。
jstack网站
jmap -dump:live,format=b,file=heap.hprof <pid> dump了两次，到JProfile中比较查看是否有异常的大对象，无发现。
提了工单问阿里云的售后，说我提供的时间段里，同台物理机的其他ECS没有CPU骤增的情况，都很平稳。
问题排查到凌晨2点，期间重发应用3次，CPU照飙，2点半抱着侥幸心理又重发了一次，CPU使用率稳定在30%一下，没有改代码，没有改配置，观察了半个小时稳定，回家睡觉，第二天起床再看，CPU稳定，启动Nginx，一切恢复正常。
撒情况？？？