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，每个类持有一个，不会多次新建。

七、本文总结

遇到线上问题不要慌，首先确认排查问题的思路：