转载

服务刚启动就 Old GC，要闹哪样？

1.背景

最近有个同学说他的服务刚启动就收到两次 Full GC 告警，按道理来说刚启动，对象应该不会太多，为啥会触发 Full GC 呢？

服务刚启动就 Old GC，要闹哪样？

带着疑问，我们还是先看看日志吧，毕竟日志的信息更多。

2.日志

可以看到，其实是两次 CMS GC（监控对 Full GC 和 Old GC 不分）。但是你会发现一个奇怪的现象，咦，"CMS-initial-mark: 0K(3222528K)" 怎么 Old Gen 对象使用空间大小为 0，细想服务刚启动，Old Gen 为 0 也算正常，但是为什么会触发CMS GC 呢？第一次 CMS GC 日志：

第二次 CMS GC 日志：

之前我整理过一篇《JVM 源码解读之 CMS GC 触发条件》文章，其中提到很多种 CMS GC 触发条件，我们来一起来分析下吧。

3.分析

首先，这必然是 CMS 的 background collector。因为 foreground collector 触发条件比较简单，一般是遇到对象分配但空间不够，就会直接触发 GC。但是 Old Gen 占用为 0，不可能申请时空间不足。因此，可以断定是 CMS 的 background collector。另外， foreground collector 是没有 Precleaning、AbortablePreclean 阶段的，因此，从 CMS GC 日志上来看，也能看出是 background collector。

既然是 CMS background collector，我们结合 JVM 参数及日志，再按照 background collector 的五大种情况一个个的排除呗。

根据是否是并行 Full GC

这种一般是由 System.gc 触发的 Full GC，且在配置了 ExplicitGCInvokesConcurrent 参数的情况下，进而将 Full GC 转成并行的 CMS GC。可以看到 JVM 配置并无此参数，而且还配置了 DisableExplicitGC 参数，它会屏蔽 System.gc。因此，排除这类情况。
根据统计数据动态计算（仅未配置 UseCMSInitiatingOccupancyOnly 时）

直接排除吧，因为 JVM 配置了 UseCMSInitiatingOccupancyOnly 参数。
根据 Old Gen 占用情况判断

这种情况主要是 Old Gen 空间使用占比情况与阈值比较，从 JVM 配置可以看到 CMSInitiatingOccupancyFraction=75 阈值设置的是 75%，目前 Old Gen 还是 0 呢，显然不符合。
根据增量 GC 是否可能会失败（悲观策略）

这种情况主要说的是在两代的 GC 体系中，如果 Young GC 已经失败或者可能会失败，JVM 就认为需要进行一次 CMS GC。我们看日志也知道，并无此类情况发生，而且 Old Gen 剩余空间还非常大，比整个 Young Gen 都大。
根据 metaspace 情况判断

这是最后一种情况了，这里主要看 metaspace 的 shouldconcurrentcollect 标志，这个标志在 metaspace 进行扩容前如果配置了 CMSClassUnloadingEnabled 参数时，会进行设置。

咋一看，JVM 参数貌似没设置这个参数呀，难道跟 metaspace 扩容无关。其实不然，CMSClassUnloadingEnabled 默认就是 true 呢。