问题产生

最近新上线的系统偶尔会报FullGC时间过长(>1s)的告警,查看GC日志,如下图所示:

 

 

 

看到GC日志,我第一时间关注到的不是GC耗时,而是GC触发的原因:Metadata GC Threshold

 

也就是 FullGC 触发的原因是因为Metaspace大小达到了GC阈值。在监控系统里面看了一下Metaspace的大小变化趋势,如下图所示:

 

 

 

按照以往的经验,Metaspace在系统稳定运行一段时间后占用空间应该比较稳定才对,但是从上图来看,Metaspace显然是呈现大幅波动。为什么呢? 

 

 

相关知识

我们知道Metaspace主要存储类的元数据,比如我们加载了一个类,那么这个类的信息就会按照一定的数据结构存储在Metaspace中。

 

Metaspace的大小和加载类的数目有很大关系,加载的类越多,Metaspace占用内存也就越大。

 

Metaspace被分配于堆外空间,默认最大空间只受限于系统物理内存。跟它相关的比较重要的两个JVM参数:

 

-XX:MetaspaceSize -XX:MaxMetaspaceSize

 

MaxMetaspaceSize,大家从名字也能猜到是指Metaspace最大值。

 

而MetaspaceSize可能就比较容易让人误解为是Metaspace的最小值,其实它是指Metaspace扩容时触发FullGC的初始化阈值。

 

在GC后Metaspace会被动态调整:如果本次GC释放了大量空间,那么就适当降低该值,如果释放的空间较小则适当提高该值,当然它的值不会大于MaxMetaspaceSize.

 

另外一个相关知识是:Metaspace中的类需要满足什么条件才能够被当成垃圾被卸载回收?

 

条件还是比较严苛的,需同时满足如下三个条件的类才会被卸载:

 

  1. 该类所有的实例都已经被回收;

     

  2. 加载该类的ClassLoader已经被回收;

     

  3. 该类对应的java.lang.Class对象没有任何地方被引用。

 

 

 

排查过程

我们可以回过头再细看GC日志,可以看出Metaspace已使用内存在FullGC后明显变小(372620K -> 158348K),说明Metaspace经过FGC后卸载了很多类。

 

从这点来看,我们有理由怀疑系统可能在频繁地生成大量”一次性“的类,导致Metaspace所占用空间不断增长,增长到GC阈值后触发FGC。

 

 

 

那么这些被回收的类是什么呢?

 

为了弄清楚这点,我增加了如下两个JVM启动参数来观察类的加载、卸载信息:

 

-XX:TraceClassLoading -XX:TraceClassUnloading

 

加了这两个参数后,系统跑了一段时间,从Tomcat的catalina.out日志中发现大量如下的日志:

 

 

 

 

 

 

到此基本可以确定Metaspace增长的元凶是这些类,那么这些类

sun.reflect.GeneratedSerializationConstructorAccessorXXX

是干嘛的呢?又是从哪里引进来的呢?我也是一脸懵逼~~ 

 

根据类名Google了一把,找到了@寒泉子写的《从一起GC血案谈到反射原理》,这篇文章对这些类的来源解释得很透彻。在这里我简单总结如下:

 

Method method = XXX.class.getDeclaredMethod(xx,xx);method.invoke(target,params);

 

这些类的来源是反射,类似上面所示的反射代码应该大家都写过或者看过,我们常用的大多数框架比如Spring、Dubbo等都大量使用反射。

 

出于性能的考虑,JVM会在反射代码执行一定次数后,通过动态生成一些类来将”反射调用”变为“非反射调用”,以达到性能更好。而这些动态生成的类的实例是通过软引用SoftReference来引用的。

 

我们知道,一个对象只有软引用SoftReference,如果内存空间不足,就会回收这些对象的内存;如果内存空间足够,垃圾回收器不会回收它。只要垃圾回收器没有回收它,该对象就可以被使用。

 

那么,究竟在什么时候会被回收呢?

 

SoftReference中有一个全局变量clock代表最后一次GC的时间点,有一个属性timestamp,每次访问SoftReference时,会将timestamp其设置为clock值。

 

当GC发生时,以下几个因素影响SoftReference引用的对象是否被回收:

 

  1. SoftReference对象实例多久未访问,通过clock - timestamp得出对象大概有多久未访问;

     

  2. 内存空闲空间的大小;

     

  3. SoftRefLRUPolicyMSPerMB常量值;

 

是否保留SoftReference引用对象的判断参考表达式,true为不回收,false为回收:

 

clock - timestamp <= freespace * SoftRefLRUPolicyMSPerMB

 

说明:

  • clock - timestamp:最后一次GC时间和SoftReference对象实例timestamp的属性的差。就是这个SoftReference引用对象大概有多久未访问过了

     

  • freespace:JVMHeap中空闲空间大小,单位为MB。

     

  • SoftRefLRUPolicyMSPerMB:每1M空闲空间可保持的SoftReference对象生存的时长(单位ms)。这个参数就是一个常量,默认值1000,可以通过参数:-XX:SoftRefLRUPolicyMSPerMB进行设置。

 

查看了一下我们系统的JVM参数配置,发现我们把SoftRefLRUPolicyMSPerMB设置为0了,这样就导致软引用对象很快就被回收了。进而导致需要频繁重新生成这些动态类。

 

为了验证这个猜测,我把SoftRefLRUPolicyMSPerMB改成了6000进行观察,发现果然猜得没错。

 

系统启动后不久Metaspace的使用空间基本保持不变了,运行几天后也没再出现因为Metaspace大小达到阈值而触发FGC。至此问题解决。

 

 

References

 

假笨说-从一起GC血案谈到反射原理: 

https://mp.weixin.qq.com/s/5H6UHcP6kvR2X5hTj_SBjA?

Java的强引用,软引用,弱引用,虚引用及其使用场景: 

http://blogxin.cn/2017/09/16/java-reference/

转载自:石衫的架构笔记 微信公众号