欢迎大家关注我的博客：Neo的博客 刚开始写会不定期更新的。

一大早刚来到公司工位上，电话响起来了，一看是运维老湿打过来到，紧张的接起电话，小心脏扑通扑通跳。“小路啊，你有个服务CPU飙到99%，现场给你保留了，赶紧看看吧！”挂了电话一看短信，果然有告警过来了！还好服务没有重启，现场保留了，赶紧上到服务器上看看。看到是一个用户评分的服务，六台机器的其中一台CPU飙升，下面介绍一下问题排查的过程和解决方法。

一、查看导致CPU飙升的线程

首先需要定位到是服务里的那些线程导致CPU飙升的。具体查找方法：
1、在服务器上通过jps -1可以查到服务的进程号。

jps -1

2、查到对应的进程号，通过top -H -p $pid，可以看到具体是哪个线程占用了CPU，记下该线程的id。

top -H -p $pid

二、查看对应线程的java堆栈信息。

根据找到的线程，可以去查看对应的java堆栈信息，来进一步定位是哪一段代码出现了问题。
通过jstack -l $pid可以查看java进程的堆栈信息，这里的pid是进程号。
在堆栈信息中nid指的就是线程id，但是这里的线程id是16进制，我们之前获取的线程id是10进制的，需要转换一下，比如我查到线程id是14533，转换后是38c5，所以在jstack -l结果中查看38c5这个线程。

jstack -l $pid 去代码里一看，原因其实很简单，多线程环境下使用了非线程安全HashMap，导致了这个问题，但是使用HashMap怎么会跑满CPU呢？google一下才知道，HashMap在多线程环境下reHash时，可能会导致死循环，具体的分析这里就不再展开了，想了解的同学可以看下这个博客：HashMap 死循环分析。
解决的方法也很简单，将原来非线程安全的HashMap替换成线程安全的ConcurrentHashMap就行了。
解决后发布，并将错误原因和修复结果反馈给运维老湿，老湿夸奖了我的响应迅速~
从这个错误中学习到，不要用主观的猜测去多线程环境下代码的工作方式，只要是多线程，一定要使用线程安全的类。