一次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