1、查看当前的tomcat线程pid。
2、查看该pid下线程对应的系统占用情况。top -Hp 384
3、发现pid4430443144324433线程分别占用了约40%的cpu
4、将这几个pid转为16进制，分别为114e114f11501151
5、下载当前的java线程栈sudo -u tomcat jstack -l 384>/1.txt
6、查询5中对应的线程情况，发现都是gc线程导致的
7、dump java堆数据
sudo -u tomcat jmap -dump:live,format=b,file=/dump201612271310.dat 384
8、使用MAT加载堆文件，可以看到javax.crypto.JceSecurity对象占用了95%的内存空间，初步定位到问题。
MAT下载地址：
http://www.eclipse.org/mat/
9、查看类的引用树，看到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，每个类持有一个，不会多次新建。
本文总结
遇到线上问题不要慌，首先确认排查问题的思路：
查看日志
查看CPU情况
查看TCP情况
查看java线程，jstack
查看java堆，jmap
通过MAT分析堆文件，寻找无法被回收的对象
