慎重！是否需要GCLockerInvokesConcurrent

简书 占小狼，转载请注明原创出处，谢谢！

对于System.gc()，可以采用-XX:+DisableExplicitGC直接避免FGC，同时也可以使用-XX:+UseConcMarkSweepGC -XX:+ExplicitGCInvokesConcurrent使用并发的方式执行FGC，当看到GCLockerInvokesConcurrent参数时，以为执行原理差不多，可以减缓GC Locker引起的GC，结果会让你失望。

如果使用了-XX:+UseConcMarkSweepGC -XX:+GCLockerInvokesConcurrent，当发生GC Locker引起的GC时，会触发类型为VM_GenCollectFullConcurrent的VM OP，实现如下：

1、A 逻辑是补偿一次YGC过程，虽然有可能这是一次多余的操作
2、B 逻辑，看注释是会推进一次CMS GC，具体是怎么个推进法，可以看下CMSCollector::request_full_gc的实现：

3、C 逻辑，设置标识_full_gc_requested，它有什么用？
4、通知在CGC_lock等待的线程

看下标识_full_gc_requested的作用：
CMS中的background collector动作，默认每隔2秒会判断一次是否需要触发，在判断方法中的最开始，有这样一段逻辑：

没错，只要标识_full_gc_requested为true，不管触发CMS的条件（比如老年代的使用率超过阈值等）是不是满足，都会触发这次CMS GC，很显然，在老年代使用率很低的时候也会被触发。

那为什么要这么实现呢？

唯一的解释：在JNI进入critical时，应线程触发的YGC，会直接在老年代分配对象，而这次提早的CMS正好可以清理这些临时对象。

还有什么解释？