(转)Java服务CPU飙到99%问题排查
一大早刚来到公司工位上，电话响起来了，一看是运维老湿打过来到，紧张的接起电话，小心脏扑通扑通跳。“小路啊，你有个服务CPU飙到99%，现场给你保留了，赶紧看看吧！”挂了电话一看短信，果然有告警过来了！还好服务没有重启，现场保留了，赶紧上到服务器上看看。看到是一个用户评分的服务，六台机器的其中一台CPU飙升，下面介绍一下问题排查的过程和解决方法。
一、查看导致CPU飙升的线程
首先需要定位到是服务里的那些线程导致CPU飙升的。具体查找方法：
1、在服务器上通过jps -1可以查到服务的进程号。
2、查到对应的进程号，通过top -H -p $pid，可以看到具体是哪个线程占用了CPU，记下该线程的id。
（注：-p 是指根据进程id查询 -H是指该进程下的线程，so此状态下的PID为线程id）
二、查看对应线程的java堆栈信息。
根据找到的线程，可以去查看对应的java堆栈信息，来进一步定位是哪一段代码出现了问题。
通过jstack -l $pid可以查看java进程的堆栈信息，这里的pid是进程号。
在堆栈信息中nid指的就是线程id，但是这里的线程id是16进制，我们之前获取的线程id是10进制的，需要转换一下，比如我查到线程id是14533，转换后是38c5，所以在jstack -l结果中查看38c5这个线程。
去代码里一看，原因其实很简单，多线程环境下使用了非线程安全HashMap，导致了这个问题，但是使用HashMap怎么会跑满CPU呢？google一下才知道，HashMap在多线程环境下reHash时，可能会导致死循环，具体的分析这里就不再展开了，想了解的同学可以看下这个博客： HashMap 死循环分析 。
解决的方法也很简单，将原来非线程安全的HashMap替换成线程安全的ConcurrentHashMap就行了。
解决后发布，并将错误原因和修复结果反馈给运维老湿，老湿夸奖了我的响应迅速~
从这个错误中学习到，不要用主观的猜测去多线程环境下代码的工作方式，只要是多线程，一定要使用线程安全的类。
