一次线上内存泄漏的问题排查
上线了好久的项目今天突然出现cpu到达100% 的情况，先将项目紧急重启，恢复正常后登录服务器排查gc日志，发现存在内存泄漏的情况。
top命令查看进程情况，top -Hp pid查看线程，再jstack导出日志。过程匆忙，忘了截图
【一次线上内存泄漏的问题排查】搜索jsatck日志看到许多线程阻塞在这一行代码
文章图片
基本可以定位到问题，是由于CertUtil中的创建的某些对象一直没有被回收导致的。而CertUtil并不是静态的，而是每次请求创建一个，因此当并发量提升时，新创建的对象会占满内存。
查看日志系统，发现果然近两天的请求数量剧增
文章图片
在mat中导入dump文件分析，可以看到与jstack日志中结论一致，JcsSecurity类中的map维护了大量的org.bouncycastle.jce.provider.BouncyCastleProvider对象，这些对象一直没有被释放，直到占满了内存空间
文章图片
JcsSecurity类源码显示其内部维护一个静态的map--verificationResults，它在调用链中只存在put操作，不存在remove操作，因此每次调用后在map中维护的value无法被回收。由此我们可以知道，该类的设计初衷，应当是让我们单例或静态调用，不应当持续创建新对象
文章图片
第一次排查OOM，其实过程远没有博客描述的这般顺利。此次事故之后，相信以后的内存问题排查会更加得心应手。
转载于:https://www.cnblogs.com/Moine/p/9940985.html
推荐阅读
- JAVA（抽象类与接口的区别&重载与重写&内存泄漏）
- 【故障公告】周五下午的一次突发故障
- 我要我们在一起（二）
- 洱海不是海，，人群没有你
- 我的拖延症如何控制了我，又一次
- 跟身体谈恋爱
- 记一次赛课失利
- Java内存泄漏分析系列之二（jstack生成的Thread|Java内存泄漏分析系列之二：jstack生成的Thread Dump日志结构解析）
- 秋已动夏未走
- 第一次组织同学们乘车