测试环境频繁Full GC问题的解决思路

背景

上游调用方，反馈当前welink-front服务不可用；

临时解决办法

手动重启welink-front服务，重启之后观测到业务日志正常刷，说明该问题暂时得到了解决；

但没过多久，上游调用方的同学又找来了，反馈当前服务又不可用了，果然该来的总是会来；

现象

直接jmap -heap [pid]打印堆内存大小，瞧着内存使用情况挺正常的；

gc日志显示，当前java服务在频繁的进行FullGC；

这里有个点，就是FullGC后，堆可用内存大小基本没怎么变化，GC了个寂寞；

细细想来，FullGC的原因无非那么几种：

1、实际业务导致堆内存短时间内暴增，例如高并发场景；

2、大对象；

3、内存泄漏，老年代存在大量释放不掉的对象；

4、元数据区满了；

5、堆外内存；

6、System.gc();

其实纠结那么多干嘛，直接jstat -gccause [pid]看GC原因就好了；

其实到这里就很明了了，元数据区内存使用率97.26%，上次GC原因为：Metadata GC Threshold，当前GC原因为：Last ditch collection；

Metadata GC Threshold：metaspace空间不能满足分配时触发，这个阶段不会清理软引用；

Last ditch collection：经过Metadata GC Threshold触发的full gc后还是不能满足条件，这个时候会触发再一次的gc cause为Last ditch collection的full gc，这次full gc会清理掉软引用；

到这里基本可以断定，就是元数据区内存不够霍霍了；根据前面堆内存打印显示，元数据区内最大为128M；这个也跟前面GC日志的结果相吻合；

所以解决方案就是直接调大堆内存和元数据区内存；

为什么是直接调大元数据区的内存大小呢?

是因为在测试环境的发布模板中，我们通常会直接将内存调小；

反思与总结

测试环境的问题，发现了应当立即定位分析根本原因，然后评估影响并确定解决方案，不要把悬念带上生产；