记一次隐藏很深的 JVM 线上惨案的分析、排查、解决

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

如下图所示。

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

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

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

其实很多人会有一个疑问，到底为什么软引用的类因为错误的参数设置被快速回收之后，就会导致JVM不停创建更多的新的类呢?

其实大家不用去扣这里的细节，这里有大量的底层JDK源码的实现，异常复杂，要真的说清楚，得好几篇文章才能讲清楚JDK底层源码的这些细节。

大家只要记住这个结论，明白这个道理就好。

10、如何解决这个问题?

虽然底层JDK的一些实现细节我们没分析，但是大致梳理出来了一个思路，大家也很清楚问题所在和原因了

解决方案很简单。在有大量反射代码的场景下，大家只要把

-XX:SoftRefLRUPolicyMSPerMB=0 

这个参数设置大一些即可，千万别让一些新手同学设置为0，可以设置个1000，2000，3000，或者5000毫秒，都可以。

提高这个数值，就是让反射过程中JVM自动创建的软引用的一些类的Class对象不要被随便回收，当时我们优化这个参数之后，就可以看到系统稳定运行了。

基本上Metaspace区域的内存占用是稳定的，不会来回大幅度波动了。

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!