一次fullgc问题分析总结

一 现象:

页面卡死,影响时长:约10min

二 排查:

1 收到报警邮件,查看日志报如下log:

Caused by: java.lang.OutOfMemoryError: Java heap space
java.lang.OutOfMemoryError: Java heap space
2 查看cpu,发现cpu跑满了,查看GC的LOG 发现一直在fullGC,频率评价是每2秒一次,每次停顿时间大约2.5s

3 查看业务日志log:

发现一直在报dubbo调上游接口根据组织批量查询下面人员信息超时

三 原因:

报表下载导致的

分析过程:下载报表逻辑是根据传入组织参数:比如某个公司,获取该公司下的所有子组织,以及全部子组织下的人,查出全量流水和全量人员,然后根据组织参数和时间段参数过滤得到想要的流水写入excel导出。问题出现在 :获取该公司下的所有子组织(可能会很多达到几万个)以及全部子组织下的人,调上游人事系统接口dubbo超时,方法的栈桢不能及时退出,大量对象引用一直存在,导致对象所占的空间不能及时通过gc回收,不断积压,导致内存泄露,频繁fullGC,stop the world,系统停顿,每次停顿时间大约2.5s,同时cpu飙升跑满,系统卡死,页面无反应。

四 改进方案:

1 减少本地缓存,不要过于依赖本地缓存,只可把高频少量的数据放入本地缓存,无论是跑批还是报表减少对上游依赖,可以只跑增量数据,减少无用数据的跑批

2 查数据增加分页控制,控制单次触发不会占用过多内存,就可以增加下载报表并发进行数量

3 报表接入大数据平台,从业务代码中剥离

原文地址:https://www.cnblogs.com/wanghongsen/p/10080557.html