来源：https://www.cnblogs.com/kingszelda/p/9034191.html

一、发现问题

下面是线上机器的cpu使用率，可以看到从4月8日开始，随着时间cpu使用率在逐步增高，最终使用率达到100%导致线上服务不可用，后面重启了机器后恢复。
在这里插入图片描述

二、排查思路

简单分析下可能出问题的地方，分为5个方向：

系统本身代码问题
内部下游系统的问题导致的雪崩效应
上游系统调用量突增
http请求第三方的问题
机器本身的问题

三、开始排查

查看日志，没有发现集中的错误日志，初步排除代码逻辑处理错误。
首先联系了内部下游系统观察了他们的监控，发现一起正常。可以排除下游系统故障对我们的影响。
查看provider接口的调用量，对比7天没有突增，排除业务方调用量的问题。
查看tcp监控，TCP状态正常，可以排除是http请求第三方超时带来的问题。
查看机器监控，6台机器cpu都在上升，每个机器情况一样。排除机器故障问题。

即通过上述方法没有直接定位到问题。

四、解决方案

重启了6台中问题比较严重的5台机器，先恢复业务。保留一台现场，用来分析问题。
查看当前的tomcat线程pid
查看该pid下线程对应的系统占用情况。top -Hp 384

top -Hp 进程pid //该进程下的线程进行观察

使用命令top -p ，显示你的Java进程的内存情况，pid是你的java进程号，比如384。按H，获取每个线程的内存情况

在这里插入图片描述

发现pid 4430 4431 4432 4433 线程分别占用了约40%的cpu

将这几个pid转为16进制，分别为114e 114f 1150 1151
//转换成为 16 进制
printf “%x” your_pid
下载当前的java线程栈 sudo -u tomcat jstack -l 384>/1.txt
查询5中对应的线程情况，发现都是gc线程导致的

jstack [进程] | grep -A 10 [线程的16进制]
即： jstack 21125 | grep -A 10 52f1

-A 10表示查找到所在行的后10行。21233用计算器转换为16进制52f1，注意字母是小写。

在这里插入图片描述

dump java堆数据

sudo -u tomcat jmap -dump:live,format=b,file=/dump201612271310.dat 384
// 获取所有对象的dump
jmap -dump:format=b,file=/tmp/heap.hprof <PID>
// 获取存活对象的dump，实际效果是先执行一次FULL GC
jmap -dump:live,format=b,file=/tmp/heap-live.hprof <PID>

heap dump会造成JVM比较长时间的停顿，必须摘流量执行
dump文件一定要zip后再传输，能节约大量传输时间

tar -zcf /tmp/heap.hprof.gz /tmp/heap.hprof

使用MAT加载堆文件，可以看到javax.crypto.JceSecurity对象占用了95%的内存空间，初步定位到问题。

MAT下载地址：http://www.eclipse.org/mat/
在这里插入图片描述

查看类的引用树，看到BouncyCastleProvider对象持有过多。即我们代码中对该对象的处理方式是错误的，定位到问题。

五、代码分析

我们代码中有一块是这样写的:
在这里插入图片描述
这是加解密的功能，每次运行加解密都会new一个BouncyCastleProvider对象,放倒Cipher.getInstance()方法中。

看下Cipher.getInstance()的实现，这是jdk的底层代码实现，追踪到JceSecurity类中
在这里插入图片描述
verifyingProviders每次put后都会remove,verificationResults只会put，不会remove。

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