项目场景:
使用sptingcloud-gateway作为网关,同一处理请求,请求量不大
问题描述
随便一个请求,直接把网关模块服务打死,CPU飙升到100%
原因分析:
统一配置中配置了黑名单策略
解决方案:
1.如何产生Dump文件
Dump文件 是在OOM内存溢出的时候,自动Dump文件转存快照的,配置JVM参数 ,就能够在发生Out of Memory错误的时候,就是把当前堆栈信息转存为快照Dump文件
-
自动 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=D:\heapdump
-
手工 jmap -dump:format=b,file=文件名 pid
选择Start Center 然后选择打开快照 OpenSnapshots
Open a Single Snapshot打开一个快照, 选择自己的 dump文件
2.Jprofiler使用 分析大对象来源
Jprofile 分析对象,有两个特别重要的信息即 对象的引用信息
incoming references
入引用, 显示这个对象被谁引用, 找问题出现的代码位置
outcoming references
出引用,显示这个对象引用的其他对象, 找出他有什么,他为什么这么大内存,内存里面存储的是啥
下面我们先预估对象内存大小
按照Size排序, 可以看到 跟我相关的对象最大的对象是1773MB, 有多少个这样的实例呢 44330248个
3.Incomming References 入引用,找引用当前对象的对象
3.1 Use select Objects 分析对象引用
首先 选中对象,点击右键,Use select Objects 选择 incoming references 找到对象引用的地方
逐个分析, 点击show more
3.2 查看代码,分析问题
4.Jprofile 大对象寻找法
上面我们通过 incomming references ,找对了对象的引用,下面我们我们采用更为直接的方法
我们都知道内存过高, 无法回收,肯定是内存中堆积的东西多了, 那么我们看下有哪些大对象占用了内存,如何找到大对象?
Jprofile提供了Biggest Objects的 查找方法
我们可以看到按钮 Biggets OBjects
直接点击按钮, JProfiler就会显示当前堆栈中有哪些大对象
然后点开大对象进行分析, 同样的 Used Selected Objects
点击Incomming References 查找对象引用信息
同样的结果, 可以定位到23行代码存在问题
5.Outgoing References 出引用, 找该对象引用的所有对象
我们知道了这个大对象,如果没有办法定位到问题发生的行数,还是很难判断内存过大的问题到底是如何产生的
这时候我们需要找出该大对象, 引用的所有对象, 看看能否从这个思路上,突破,找到问题,此刻就需要 Outgoing References 出引用,找到该对象引用的所有对象
同样的 Used Selected Objects
然后选择 Outgoing References 出引用信息
然后点开分析该对象到底引用了哪些对象,可以看到具体的对象信息
比如我的ConcurrentHashMap的key是 jvmtestApplication
分析文档原文:
https://vip.kingdee.com/article/660426204759182080?productLineId=29&lang=zh-CN