java每隔一小时fullgc_项目周期性fullGc间隔为1小时

现象:

image

可以看到fullGc间隔时间为1小时.

同事看到这个现象后反馈说,这可能和tomcat的版本过低有关系.tomcat6.0为了避免内在溢出会通过system.gc()触发fullGc, 建议我们升级tomcat. 于是确认了一下,发现jdk和tomcat的版本信息为

image

确实是非常低,无论如何也该升级了. 在升级前当然要先看看fullGc的原因了.于是通过

-XX:&＃43;PrintGCDetails

输出gc信息,这个默认是输出到控制台的,所以在catalina.out中也是可以看到的.

image

可以看到老年代根本没有达到最大值,通过[Full GC (System)也能说明fullGc是通过System.gc()调用的

于是升级到jdk1.8 ,tomcat8.0 ,启动,本以为就此结束,没想到系统在启动时就先来了三次fullGc,这还真是个惊喜.

通过 jstat -gcutil pid 1000 5 查看如下

image

输出的日志信息如下

image

full gc 原因都是一样的: MetaData GC Threshold , 通过查阅资料及现场日志可以看出是Metaspace空间不够了,扩了三次.发生了三次fullGc

Metaspace 默认为20M左右,通过日志信息可以看出来

于是 设定Metaspace大小

-XX:MetaspaceSize&＃61;128M

再次重启,果然不在full Gc了,经过一段时间的监控,发现不会在频繁fullGc了

image

本以为周期性fullGc问题就这样结束时,新的问题接踵而来.

在升级另一个项目的jdk及tomcat版本后,惊奇的发现又出现了周期性fullGc的问题,间隔时间还是一个小时.而且项目在启动时就会来一次fullGc

image

这就纳闷了,我tomcat已经升级到8.0了,怎么还会出现呢? 没关系,把上面排查的路在走一遍.

1,查看gc日志

image

发现是system.gc().

2,排查tomcat,发现已经不存在之前的问题.

3,尝试本地复现

本地成功复现,周期也为1小时. 猜测可能是某个组件导致的,因为太规律了,但靠猜站不住脚,还得去跟踪.

使用VisualVM 跟踪这个进程,先看下有没有特殊的线程,发现有个 GC Daemon 的守护线程

image

有经验的同事可能已经从线程的堆栈信息中看出门道了.但我这时还没有察觉.

于是引入了BTrace, BTrace功能很强大,可以方便的获取程序运行时的数据信息&＃xff0c;如方法参数、返回值、全局变量和堆栈信息等. 在VisualVM中有BTrace的插件,直接安装就可以.

image

然后打开.

image

出现这个界面

image

然后输入以下代码:

/* BTrace Script Template */

import com.sun.btrace.annotations.*;

import static com.sun.btrace.BTraceUtils.*;

&＃64;BTrace

public class TracingScript {

/* put your code here */

&＃64;OnMethod(clazz &＃61; "java.lang.System", method &＃61; "gc")

public static void onSystemGC() {

println("entered System.gc()");

jstack();

}

}

java.lang.System 是我们要跟踪的类, gc是system中的方法名. 因为gc日志中显示是通过这个方法调用的. jstack() 是打出堆栈信息

然后点上面的start

image

出现下面的 ** BTrace up&running就明在正常运行了,这样当System.gc()被调用的时候就会打出堆栈信息.

结果如下 (发生两次fullGc)

image

可以发现是sun.misc.GC调用了这个线程.这个与刚刚 Thread中的信息其实是一致的.

于是项目中搜索这个关键字,不要忘记jar包也要排查.

排查到在cxf-common-utilities-2.2.10.jar 的JDKBugHacks 类中有调用

image

通过注释能够看出是为了防止可能的内存溢出而周期性调用.

看了下这个组件的新版本,对这块已经进行了优化

image

调整为10小时一次,同时增加了一个 控制参数 : -Dorg.apache.cxf.JDKBugHacks.gcRequestLatency&＃61;true ,在jvm参数上配置后即可不启用周期性fullGc.

这个apache cxf组件我没有用过,查阅后发现是和webservice有关的一个组件.本项目已经不在使用webservice,但代码没有梳理干净.于是排查下相关点,去掉了这个组件.再次预发布.

image

目前发现没有在fullGc了

总结:

1. 在软件项目的生命周期中,软件维护是最后一个阶段&＃xff0c;也是持续时间最长&＃xff0c;花费代价最大的一个阶段,确定无用的代码一定要及时清理,提升项目清洁度,降低后继运维成本.

2. 在升级jdk及tomcat时要考虑到其它组件的版本适配,虽然是向下兼容的,但还是要做好测试.

参考文档: