一、查看导致CPU飙升的线程
首先需要定位到是服务里的那些线程导致CPU飙升的。具体查找方法：
1、在服务器上通过jps -l可以查到服务的进程号。
2、查到对应的进程号，通过top -H -p $pid，可以看到具体是哪个线程占用了CPU，记下该线程的id。
二、查看对应线程的java堆栈信息
根据找到的线程，可以去查看对应的java堆栈信息，来进一步定位是哪一段代码出现了问题。
通过jstack -l $pid可以查看java进程的堆栈信息，这里的pid是进程号。
在堆栈信息中nid指的就是线程id，但是这里的线程id是16进制，我们之前获取的线程id是10进制的，需要转换一下，比如我查到线程id是14533，转换后是38c5，所以在jstack -l结果中查看38c5这个线程。
去代码里一看原因其实很简单，多线程环境下使用了非线程安全HashMap，导致了这个问题，但是使用HashMap怎么会跑满CPU呢？去查了一下才知道，HashMap在多线程环境下reHash时，可能会导致死循环，具体的分析这里就不再展开了，想了解的同学可以看下这个博客：HashMap 死循环分析。
解决的方法也很简单，将原来非线程安全的HashMap替换成线程安全的ConcurrentHashMap就行了。
解决后发布，并将错误原因和修复结果反馈给运维老湿，老湿夸奖了我的响应迅速~
这个错误告诉我，不要用主观的猜测去多线程环境下代码的工作方式，只要是多线程，一定要使用线程安全的类。