在某次测试的过程中,突然发现后端底层​​user​​​服务突然就挂了,用户量并不大,几个人用着用着就不行了。中间层发现大量超时报错,后来去查看​​user​​​服务的GC日志,发现了一个非常奇怪的现象:​​Full GC​​​次数竟然比​​Young GC​​​次数还高。下图是停止请求之后的​​GC​​统计:

超大对象导致Full GC超高的BUG分享_Java

中间某个时刻抓到的一秒内两次​​Full GC​​异常情况:

超大对象导致Full GC超高的BUG分享_Java_02

然后去翻看了​​GC日志​​​,发现了很多次​​GC​​失败的信息:

超大对象导致Full GC超高的BUG分享_linux_03

随后为了让服务正常跑起来,配置翻了倍,然后停止所有测试,只留一个账号用于调试,发现勉强还能撑住,最终才发现了问题所在:中间层服务调用后端查询接口时候,限制数量的参数没传进去,导致每次查询都查的全量信息,大概4万多条。

每一个中间层过来的请求,​​user​​​一开始还能处理,很快就不行了,因为创建了非常大的​​List​​,再加上查询消耗资源较多,所以服务就挂了。

但是,为什么​​Full GC​​​会比​​Young GC​​,我就想起来前两天看的书里面,关于Java分配大对象的知识,如下:

超大对象导致Full GC超高的BUG分享_自动化测试_04

原来超大对象可能会被直接在​​老生代​​​里面,然后就导致了​​Full GC​​​频繁,由于内存不足,就导致了​​Full GC​​失败。

  • 郑重声明:公众号“FunTester”,禁止第三方(腾讯云除外)转载、发表。