原文出处： kingszelda

一、发明问题

下面是线上呆板的cpu利用率，可以看到从4月8日开始，跟着时间cpu利用率在慢慢增高，最终利用率到达100%导致线上处事不行用，后头重启了呆板后规复。

二、排查思路

简朴阐明下大概出问题的处所，分为5个偏向：

1. 系统自己代码问题
2. 内部下游系统的问题导致的雪崩效应
3. 上游系统挪用量突增
4. http请求第三方的问题
5. 呆板自己的问题

三、开始排查

1. 查察日志，没有发明会合的错误日志，昆山软件开发，劈头解除代码逻辑处理惩罚错误。
2. 首先接洽了内部下游系统调查了他们的监控，发明一起正常。可以解除下游系统妨碍对我们的影响。
3. 查察provider接口的挪用量，比拟7天没有突增，解除业务方挪用量的问题。
4. 查察tcp监控，TCP状态正常，昆山软件开发，可以解除是http请求第三方超时带来的问题。
5. 查察呆板监控，6台呆板cpu都在上升，每个呆板环境一样。解除呆板妨碍问题。

即通过上述要领没有直接定位到问题。

四、办理方案

1.重启了6台中问题较量严重的5台呆板，先规复业务。保存一台现场，用来阐明问题。

2.查察当前的tomcat线程pid

3.查察该pid下线程对应的系统占用环境。top -Hp 384

4.发明pid 4430 4431 4432 4433 线程别离占用了约40%的cpu

5.将这几个pid转为16进制，别离为114e 114f 1150 1151

6.下载当前的java线程栈 sudo -u tomcat jstack -l 384>/1.txt

7.查询5中对应的线程环境，发明都是gc线程导致的 

8.dump java堆数据

sudo -u tomcat jmap -dump:live,format=b,file=/dump201612271310.dat 384

9.利用MAT加载堆文件，可以看到javax.crypto.JceSecurity工具占用了95%的内存空间，劈头定位到问题。

MAT下载地点：http://www.eclipse.org/mat/

 10.查察类的引用树，看到BouncyCastleProvider工具持有过多。即我们代码中对该工具的处理惩罚方法是错误的，定位到问题。

五、代码阐明

我们代码中有一块是这样写的

这是加解密的成果，每次运行加解密城市new一个BouncyCastleProvider工具,放倒Cipher.getInstance()要领中。

看下Cipher.getInstance()的实现，这是jdk的底层代码实现，昆山软件公司，追踪到JceSecurity类中

 

verifyingProviders每次put后城市remove,verificationResults只会put，不会remove.

看到verificationResults是一个static的map，即属于JceSecurity类的。

所以每次运行到加解密城市向这个map put一个工具，而这个map属于类的维度，所以不会被GC接纳。这就导致了大量的new的工具不被接纳。

六、代码改造

将有问题的工具置为static，每个类持有一个，不会多次新建。

七、本文总结

碰着线上问题不要慌，首先确认排盘查题的思路：

1. 查察日志
2. 查察CPU环境
3. 查察TCP环境
4. 查察java线程，jstack
5. 查察java堆，jmap
6. 通过MAT阐明堆文件，寻找无法被接纳的工具