一个不合理的 JVM 参数设置引发的一场线上惨案。。。

07/05 11:46
阅读数 339

凌晨3点,一阵急促的铃声把老王惊醒。。。

“老大,线上系统好像出问题了,频繁Full GC,系统一直处于卡顿状态。。。”

听到Full GC的那一刻,老王就已睡意全无,他知道,马上又要看到凌晨3点的北京了。

“小猛,先别着急,你和彪子先去线上看看GC日志,我这边马上赶到!”

想想自己的年终奖、KPI,看着自己熟睡的儿子,老王哪敢怠慢,匆匆穿上衣服,一头扎进北京初冬的寒风中。。。

一小时后,某创业公司。。。

空荡荡的写字楼灯火通明,两个年轻的工程师正在紧张的操作,时不时的交头接耳。

老王快步向前,也顾不得跟两个小弟打招呼,连忙问道:现在情况怎么样?

“还是跟之前一样,频繁Full GC,系统卡死。。。”,小猛和彪子不敢隐瞒,马上把情况报告给老大

查看 JVM GC 日志

没有一丝耽搁,老王立刻调出了线上GC日志,在日志里,看到了一个“Metadata GC  Threshold”的字样,类似于如下日志:

【Full GC(Metadata GC  Threshold)xxxxx, xxxxx】

通过GC日志,老王立即定位到这次频繁的Full GC,实际上是JDK 1.8以后的Metadata元数据区导致的。

奇怪了,Metadata区域一般是放一些加载到JVM里去的类,为什么会被频繁的塞满,进而触发Full GC呢?

老王陷入了沉思,一旁的小猛和彪子只是静静的看着,大气也不敢出。。。

查看 Metaspace 内存占用情况

对啊,怎么把这茬给忘了”。老王突然的自言自语,把两个小弟吓了一跳。

思考中的老王根本没注意到两个小弟的反应,他迅速通过jstat,观察了一下Metaspace内存区域占用的波动曲线图,发现图像类似下面这样:

看起来Metaspace区域的内存呈现一个波动的状态,总是会先不断增加,达到一个顶点之后,就会把Metaspace区域给占满

占满之后,自然就会触发一次Full GC,Full GC会带着Metaspace区域的垃圾回收,所以接下来Metaspace区域的内存占用又变得很小了。

看着屏幕上的图像,老王心里一丝明悟。很明显系统在运行过程中,不停的有新的类产生被加载到Metaspace区域里,然后不停的把Metaspace区域占满。接着触发一次Full GC,回收掉Metaspace区域中的部分类。

然后这个过程不断循环,进而造成Metaspace区域反复被占满,然后反复导致Full GC的发生

老王一边思考,一边在纸上画出了一张示意图:

到底是什么类在不停的加载?

那问题又来了,到底是什么类不停的被加载到JVM的Metaspace区域里去?老王又一次陷入了沉思。

不多会,他回过神来,在JVM启动参数中加入如下两个参数了:

-XX:TraceClassLoading 

-XX:TraceClassUnloading

“老大,这两个参数有什么作用啊?”彪子忍不住好奇问道。

“这两个参数,顾名思义,就是追踪类加载和类卸载的情况,他会通过日志打印出来JVM中加载了哪些类,卸载了哪些类”,老王一边紧盯屏幕,一边解释道。

果然,加入这两个参数之后,在Tomcat的catalina.out日志文件中输出了一堆日志,里面显示类似如下的内容:

【Loaded sun.reflect.GeneratedSerializationConstructorAccessor from __JVM_Defined_Class】

明显可以看到,JVM在运行期间不停的加载了大量的名字叫做“GeneratedSerializationConstructorAccessor”类到Metaspace区域里去

看着这个莫名其妙的类,老王在之前的草图上又补充了几笔:

虽然不知道这是什么类,但是老王相信就是它的一直加载,导致 Metaspace 区域不停被占满,进而不停的引发Full GC

直觉告诉他,已经慢慢接近真相了!

为什么会频繁加载奇怪的类?

“彪子,你马上百度一下这个类是什么?”老王指着刚才日志追踪到的这个奇怪的类名说道。

“好的好的”,彪子哪敢怠慢,三下五除二就百度了出来

“老大,这个类是Java执行反射机制时加载出的一个类,JVM会在反射调用一定次数之后动态生成一些类,刚才这个类就是其中之一,这个是JVM的一个底层优化机制”

彪子念完上面一段话,一脸懵逼,自己都不知道自己在说啥。。。

不停执行反射代码后动态生成的类。。。老王陷入沉思,边思考边在纸上又画出了一张图:

JVM 创建的奇怪类的玄机

经过短暂的思考后,老王一丝恍悟。想到了自己在公众号儒猿技术窝的专栏《从零开始带你成为JVM实战高手》里学过的如下知识:

JVM在反射过程中动态生成的类的Class对象,他们都是SoftReference软引用的,而软引用正常情况下不会回收,但是如果内存比较紧张的时候就会回收这些对象。

那SoftReference对象到底在GC的时候要不要回收,是怎么判断的呢?老王大脑继续飞速运转

对了,就是这个!老王一拍大腿,在纸上迅速写下了一个等式。

clock - timestamp <= freespace * SoftRefLRUPolicyMSPerMB

看着老大写出的这个公式,两个小弟的反应完全不同。小猛一脸懵逼,而彪子则一脸淡然。

彪子看到好哥们小猛的反应,主动给他解释道:“clock - timestamp”代表了一个软引用对象有多久没被访问过了。freespace代表JVM中的空闲内存空间,SoftRefLRUPolicyMSPerMB代表每一MB空闲内存空间可以允许SoftReference对象存活多久。”

“举个例子,假如现在JVM创建了一大堆奇怪的类出来,这些类本身的Class对象都是被SoftReference软引用的。”

“然后现在JVM里的内存空间有3000MB,SoftRefLRUPolicyMSPerMB的默认值是1000毫秒,那么就意味着,此时那些奇怪的SoftReference软引用的Class对象,可以存活3000 * 1000 = 3000秒,就是50分钟左右。”

“是的,小彪说的没错”,老王一边思考,一边评价着彪子刚才的一番解答

得到了老大的认可,彪子心里一阵小得意,而小猛则是一脸不可思议,心想:“这货跟我合租一套房,白天一块上班,晚上一块开黑,这些东西哪里看的”

其实他不知道的是,彪子游戏玩的很渣,每局都早早的挂掉了,所以在等待下一局的时候,就会无聊逛逛技术博客啥的

刚才说的这些,就是在他等待玩下一把游戏之前的空隙,无意中get到的

但是,正是因为彪子get到的这个他引以为傲的“黑科技”,导致了今天这次线上事故。

怎么回事儿呢?我们接着看!

话说老王在肯定了彪子对自己写下的这个等式的解释后,又继续说道:

“当然小彪上面那个例子,仅仅是举例而已。一般来说,发生GC时,其实JVM内部或多或少总有一些空间内存的,所以基本上如果不是快要发生OOM内存溢出了,一般软引用也不会被回收。”

“所以按理说,JVM应该会随着反射代码的执行,动态的创建一些奇怪的类,他们的Class对象都是软引用的,正常情况下不会被回收,也不应该快速增长。”

问题解决,水落石出

分析到这里,老王感觉自己离解决方案就差一层窗户纸,一捅就破。

眼睛紧紧盯着纸上的公式,他忽然想到了什么,打开了线上的JVM参数设置,找到刚才公式里的参数:SoftRefLRUPolicyMSPerMB

“果然是它”,老王自言自语道,随后他快速敲击着键盘,重新设置了JVM参数,重启之后,系统稳定运行了

“神了。。。老大,你怎么解决的?”小猛和彪子一脸的崇拜和不可思议。

老王并没有理会两个小弟的问题,反问道:“这个SoftRefLRUPolicyMSPerMB参数,是谁设置为0的?”

“额。。。是我设置的!”彪子额头上顿时冷汗岑岑。

不过他马上补充道:“是我没事的时候在网上逛技术博客,偶然看到了关于这个JVM参数的讲解,以及软引用什么时候被JVM垃圾回收的判断依据”。

说到这里,彪子指了指老王写在纸上的公式,“就是老大你写的这个等式”。

“然后我想着把SoftRefLRUPolicyMSPerMB这个参数设置为0,任何软引用对象就可以尽快释放掉,不用留存,尽量给内存释放空间出来,这样就可以提高内存利用效率了!”

老王听完一阵苦笑,缓缓的吐出5个字:“很傻很天真。。。

稍微顿了顿,他给彪子解释了起来:“实际上一旦这个参数设置为0之后,直接导致clock-timestamp<=freespace*SoftRefLRUPolicyMSPerMB这个公式的右半边是0,就导致所有的软引用对象,比如JVM生成的那些奇怪的Class对象,刚创建出来就可能被一次Young GC给带着立马回收掉一些。”

边说老王还边给彪子画了一张图:

“举个例子,比如JVM好不容易给你弄出来100个这种奇怪的类,结果因为你瞎设置软引用的参数,导致突然一次GC就给你回收掉几十个类”

“接着JVM在反射代码执行的过程中,就会继续创建这种奇怪的类,在JVM的机制之下,会导致这种奇怪类越来越多。”

“也许下一次gc又会回收掉一些奇怪的类,但是马上JVM还会继续生成这种类,最终就会导致Metaspace区域被放满了,一旦Metaspace区域被占满了,就会触发Full GC,然后回收掉很多类,接着再次重复上述循环”

老王一边说,一边又画出了一张图:

老王紧接着继续说道:“其实解决方案很简单,在有大量反射代码的场景下,只要把-XX:SoftRefLRUPolicyMSPerMB这个参数设置大一些即可,千万别设置为0,可以设置个1000,2000,3000,或者5000毫秒,都可以。”

“提高这个数值,就是让反射过程中JVM自动创建的软引用的一些类的Class对象不要被随便回收,你看我优化这个参数之后,系统是不是就稳定运行了,然后Metaspace区域的内存占用也是稳定的,不会来回大幅度波动了”

两个小弟听得入了迷。。。

还是小猛先回过神来:“老大,虽然最后解决方案看起来很简单,但是我觉得整个过程中的问题定位和分析才是重点,可以教教我吗?”小猛一脸的求知若渴

“是的是的”,彪子赶紧附和着说道。

老王似乎并没有打算回答两个小弟的问题,相反他脸上显现出一丝小小的失望。

叹了口气,他反问小猛和彪子:“这个月1号,我给你们布置过什么任务?”

看了看日子,1号是周五,小猛和彪子面面相觑。唯一记得的,就是那天他俩下班后,一起吃了个饭,然后就相约回出租屋里,开黑玩王者,一直到深夜!

见两个小弟陷入沉思,老王打破沉默:“我是不是给你们推荐了一个专栏《从零开始带你成为JVM实战高手》,并且交待你们用几周的时间,好好消化里面的内容!

顿了顿,老王又继续说道:“今天能这么迅速的解决这个线上事故,不是我多神,而是因为这个案例正是专栏里讲的一个案例。

我把整个专栏反复阅读了3遍,甚至可以告诉你们,这个案例在专栏的第59讲”

小猛和彪子闻言大惊,纷纷掏出手机,退出之前还在的王者荣耀界面,进入公众号儒猿技术窝的知识店铺,翻到第59讲,标题赫然在目:

老王继续说道:“不论是平时工作,还是跳槽面试,JVM一直是咱们Java程序员的一大痛点。以前我自己也看过不少JVM书籍,理论知识掌握了不少,但是对于线上实战和性能优化,总感觉心里很虚”

而《从零开始带你成为JVM实战高手》专栏,可以说填补了国内 JVM 实战这块技术资料的空白,它深入讲解了下面三块实战内容:

1.线上系统的JVM参数优化实战:基于百万交易量的支付系统、上亿用户量的电商系统实战

2.线上系统的JVM GC调优实战:基于每秒10万并发的BI系统、日百亿数据量的数据处理系统进行实战

3.线上系统的OOM内存溢出优化实战:基于百万连接网关系统、10万并发量的秒杀系统,进行实战

专栏作者救火队队长是阿里p9的资深技术专家,有 10 多年的JVM线上实战经验。

他在专栏里详细剖析了自己亲身经历的34个真实线上JVM生产案例,非常适用于我们这种中小型的创业公司

除了实战,专栏也有非常详细的对JVM原理性知识的讲解,而且写作方式很接地气,一步一图,循序渐进、通俗易懂

你们看看这个专栏大纲,也能体会到作者设计大纲的用心良苦了

更多专栏详细信息,以及专栏试读,可以扫描下方二维码了解:

说明

本文故事为公众号儒猿技术窝专栏:《从零开始带你成为 JVM 实战高手》读者在项目中的真实经历,故事中人物均为化名

End

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部