033-严重Full GC导致系统直接卡死的优化实战

92次阅读
没有评论

共计 1302 个字符,预计需要花费 4 分钟才能阅读完成。

案例实战:电商大促活动下,严重Full GC导致系统直接卡死的优化实战!

背景

033-严重Full GC导致系统直接卡死的优化实战

033-严重Full GC导致系统直接卡死的优化实战

案例是这样,有一次一个新系统上线,平时都还算正常,结果有一次大促活动的时候,这个系统就直接卡死不动了

大家注意,是直接卡死不动!也就是说,所有请求到这个系统就直接卡住无法处理,无论如何重启这个系统都没任何效果。

这个时候我们当然会想,是不是按照之前的思路,一点一点去分析JVM的GC问题,考虑是不是过于频繁的GC问题导致了系统被卡死?

那当然是会按照之前的思路去分析的,首先使用jstat去看一下系统运行情况,令人吃惊的事情是:JVM几乎每秒都执行一次Full GC,每次都耗时几百毫秒。

我们当时就惊呆了,为什么每秒都有一次Full GC?

结果更加令人吃惊的事情还在后面:我们通过jstat看了一下JVM各个内存区域的使用量,基本都没什么问题,年轻代对象增长并不快,老年代才占用了不到10%的空间,永久代也就使用了20%左右的空间

为什么会频繁触发Full GC呢?

这个时候我们立马想到了一个问题,是不是有人在系统里写了一行致命的代码:System.gc()

这个“System.gc()”可不能随便瞎写,他每次执行都会指挥JVM去尝试执行一次Full GC,连带年轻代、老年代、永久代都会去回收。

所以我们立马找到那个系统负责开发的同学,让他排查了一下自己的代码。

其实说是排查,无非就是在开发IDE中开启代码全局搜索找一下是否有“System.gc()”,结果没想到还真的找到了!

所以致命的问题就在这里,当时这个同学写这行代码想的特别的天真和可爱,出发点也是好的

他是这么考虑的,大家可以看看他当时的思路:他在代码里经常会一下子加载出来一大批数据,一旦请求处理完毕之后,他就觉得,一大批数据就废弃不用了,占据内存太多了,完全可以主动用“System.gc()”代码触发一次GC,把他们回收掉!

结果呢,平时系统运行时,访问量很低,基本还不会出大乱子!但是在大促活动的时候,访问量一高,立马由“System.gc()”代码频繁触发了Full GC,导致了这个系统直接被卡死了!

原来关键点就在于这里!

这个案例很短,也很简单,发在周末,让大家轻松看一看,不太烧脑,这周之前的几个案例,都略微有点烧脑,而且都在4000字以上,甚至需要大家看两遍才能理解其中的内容和精髓

这篇文章轻松一点,就带给大家一个小的知识点,相信大家看着也很容易。

所以,针对这个问题,一方面大家平时写代码的时候,不要自己使用“System.gc()”去随便触发GC,一方面可以在JVM参数中加入这个参数:-XX:+DisableExplicitGC。这个参数的意思就是禁止显式执行GC,不允许你来通过代码触发GC。

所以推荐大家将“-XX:+DisableExplicitGC”参数加入到自己的系统的JVM参数中,或者是加入到公司的JVM参数模板中去。避免有的开发工程师好心办坏事,代码中频繁触发GC就不好了。

正文完
 
yangleduo
版权声明:本站原创文章,由 yangleduo 2023-05-10发表,共计1302字。
转载说明:除特殊说明外本站文章皆由CC-4.0协议发布,转载请注明出处。