一、背景

某日早上，生产环境告警群出现了大量响应时间在1s多的慢接口，在应用日志中也能找到不少接口超时熔断（响应时间>=5s）。

当中有不少接口的 SQL 是能使用 索引 的，经过 DBA 排查，数据库没有问题。

在主机上使用top命令查看 Cpu 占用情况，发现有异常：部分主机 CPU 在50%上下，其中一台主机CPU偶尔就上到300%，一直持续。

二、CPU高排查

1.查消耗Cpu最高的进程 Pid 41594

shell 命令：top -c

2.根据 PID 查出消耗Cpu最高的 线程 号 41600

shell命令：top -Hp 41594

3.这是十进制的数据，转成十六进制为 a280

shell命令：printf “%xn” 41600

4.导出PID的堆栈信息

shell命令：jstack -l 41594 > 41594.stack

5.在41594.stack中搜索线程号关键字“a280”，发现以下行

“GC task thread#4 (ParallelGC)” os_prio=0 tid=0x00007f41f8026800 nid=0xa280 runnable

搜了top 5的线程号，发现都是GC的线程，说明是 堆内存出了问题 。

三、监控情况

通过Grafana监控查看 JVM 内存以及GC情况，发现堆内存基本满了

GC次数和时间明显增加

这种情况下就需要获取内存快照来分析，导出内存快照

shell命令：jmap -dump:format=b,file=dump-20210809.hprof 41594

压缩文件后在进行下载

shell命令压缩：tar -czf dump-20210809.hprof.tar.gz dump-20210809.hprof

shell命令下载：sz dump-20210809.hprof.tar.gz

四、dump分析

利用工具MemoryAnalyzer（MAT）分析dump文件，发现1.4G的内存都是com.alibaba.fastjson.parser.ParserConfig这个类占用的

展开list_objects视图查看发现1.4G都耗在com.alibaba.fastjson.util.IdentityHashMap

​网上查询相关资料，发现也有相关问题：

在代码中搜索关键字‘ ParameterizedTypeImpl ’，果然是有使用的

​ 至此，问题已经定位到，跟资料说的一模一样。

接下来就要重现这个问题，写一段循环不停的执行这段代码，循环10万次，然后把堆内存dump出来对比。

​结果如下，有346M都是com.alibaba.fastjson.parser.ParserConfig这个类占用的

com.alibaba.fastjson.util.Identity HashMap 表现也一致

​网上资料也提供了相关的解决方案，这里使用了‘方法二’

​再dump出堆内存快照，com.alibaba.fastjson.parser.ParserConfig已经不出现在视图里了