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

凌晨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