关于CMS垃圾收集算法的一些疑惑

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

对于CMS垃圾收集算法，一直有一些疑惑：
1、cms gc 和 full gc 有什么区别 ？
2、cms gc 和 full gc 如何触发的 ？
3、什么场景下会发生 concurrent model failure ？
4、full gc 每次都会进行compact么？
5、...(如果有疑惑继续更新)

虽然CMS算法已经被遗弃了，但考虑到目前还有很大一部分应用跑在该算法之下，是时候读一遍源码来加深理解了，不过最近得了一种一看源码就头疼的病，所以这部分源码断断续续看了好几天，然后趁这个机会好好的梳理一下，如果期间存在问题，欢迎指出。

cms gc 状态

当触发 cms gc 对老年代进行垃圾收集时，算法中会使用_collectorState变量记录执行状态，整个周期分成以下几个状态：

• Idling：一次 cms gc 生命周期的初始化状态。
• InitialMarking：根据 gc roots，标记出直接可达的活跃对象，这个过程需要stw的。
• Marking：根据 InitialMarking 阶段标记出的活跃对象，并发迭代遍历所有的活跃对象，这个过程可以和用户线程并发执行。
• Precleaning：并发预清理。
• AbortablePreclean：因为某些原因终止预清理。
• FinalMarking：由于marking阶段是和用户线程并发执行的，该过程中可能有用户线程修改某些活跃对象的字段，指向了一个非标记过的对象，在这个阶段需要重新标记出这些遗漏的对象，防止在下一阶段被清理掉，这个过程也是需要stw的。
• Sweeping：并发清理掉未标记的对象。
• Resizing：如果有需要，重新调整堆大小。
• Resetting：重置数据，为下一次的 cms gc 做准备。

cms gc 和 full gc 的区别

CMS算法中实现了cms gc 和 full gc，姑且这么认为吧，算法实现都位于文件concurrentMarkSweepGeneration.cpp中。

cms gc 通过一个后台线程触发，触发机制是默认每隔2秒判断一下当前老年代的内存使用率是否达到阈值，当然具体的触发条件没有这么简单，如果是则触发一次cms gc，在该过程中只会标记出存活对象，然后清除死亡对象，期间会产生碎片空间。

full gc 是通过 vm thread 执行的，整个过程是 stop-the-world，在该过程中会判断当前 gc 是否需要进行compact，即把存活对象移动到内存的一端，可以有效的消除cms gc产生的碎片空间。

cms gc 如何触发

对于 cms gc 来说，触发条件很简单，实现位于 ConcurrentMarkSweepThread 类中，相当于Java 中的Thread，该线程随着堆一起初始化，在该类的 run 方法中有这么一段逻辑：

while (!_should_terminate) {
    sleepBeforeNextCycle();
    if (_should_terminate) break;
    GCCause::Cause cause = _collector->_full_gc_requested ?
      _collector->_full_gc_cause : GCCause::_cms_concurrent_mark;
    _collector->collect_in_background(false, cause);
}

sleepBeforeNextCycle()保证了最晚每 2 秒（-XX:CMSWaitDuration）进行一次判断，实现如下：

void ConcurrentMarkSweepThread::sleepBeforeNextCycle() {
  while (!_should_terminate) {
    if (CMSIncrementalMode) {
      icms_wait();
      return;
    } else {
      // Wait until the next synchronous GC, a concurrent full gc
      // request or a timeout, whichever is earlier.
      wait_on_cms_lock(CMSWaitDuration);
    }
    // Check if we should start a CMS collection cycle
    if (_collector->shouldConcurrentCollect()) {
      return;
    }
    // .. collection criterion not yet met, let's go back
    // and wait some more
  }
}

其中shouldConcurrentCollect()方法决定了是否可以触发本次 cms gc，分为以下几种情况：

1、如果_full_gc_requested为真，说明有明确的需求要进行gc，比如调用System.gc();

2、CMS 默认采用 jvm 运行时的统计数据判断是否需要触发 cms gc，如果需要根据 CMSInitiatingOccupancyFraction 的值进行判断，需要设置参数-XX:+UseCMSInitiatingOccupancyOnly

3、如果开启了UseCMSInitiatingOccupancyOnly参数，判断当前老年代使用率是否大于阈值，则触发 cms gc，该阈值可以通过参数-XX:CMSInitiatingOccupancyFraction进行设置，如果没有设置，默认为92%；

4、如果之前的 ygc 失败过，或则下次新生代执行 ygc 可能失败，这两种情况下都需要触发 cms gc；

5、CMS 默认不会对永久代进行垃圾收集，如果希望对永久代进行垃圾收集，需要设置参数-XX:+CMSClassUnloadingEnabled，如果开启了CMSClassUnloadingEnabled，根据永久带的内存使用率判断是否触发 cms gc；

6、...还有一些其它情况

如果有上述几种情况，说明需要执行一次 cms gc，通过调用_collector->collect_in_background(false, cause) 进行触发，注意这个方法名中的in_background

full gc 如何触发

触发 full gc 的主要原因是在eden区为对象或TLAB分配内存失败，导致一次 ygc，在 GenCollectorPolicy 类的satisfy_failed_allocation()方法中有这么一段逻辑：

if (!gch->incremental_collection_will_fail(false /* don't consult_young */)) {
    // Do an incremental collection.
    gch->do_collection(false            /* full */,
                       false            /* clear_all_soft_refs */,
                       size             /* size */,
                       is_tlab          /* is_tlab */,
                       number_of_generations() - 1 /* max_level */);
  } else {
    if (Verbose && PrintGCDetails) {
      gclog_or_tty->print(" :: Trying full because partial may fail :: ");
    }
    // Try a full collection; see delta for bug id 6266275
    // for the original code and why this has been simplified
    // with from-space allocation criteria modified and
    // such allocation moved out of the safepoint path.
    gch->do_collection(true             /* full */,
                       false            /* clear_all_soft_refs */,
                       size             /* size */,
                       is_tlab          /* is_tlab */,
                       number_of_generations() - 1 /* max_level */);
  }

该方法是由 vm thread 执行的，整个过程都是 stop-the-world，如果当前incremental_collection_will_fail方法返回 false，则会放弃本次的 ygc，直接触发一次 full gc，incremental_collection_will_fail实现如下：

bool incremental_collection_will_fail(bool consult_young) {
    // Assumes a 2-generation system; the first disjunct remembers if an
    // incremental collection failed, even when we thought (second disjunct)
    // that it would not.
    assert(heap()->collector_policy()->is_two_generation_policy(),
           "the following definition may not be suitable for an n(>2)-generation system");
    return incremental_collection_failed() ||
           (consult_young && !get_gen(0)->collection_attempt_is_safe());
  }

其中参数 consult_young 为 false，如果incremental_collection_failed()返回 true，会导致执行很慢很慢很慢的full gc，如果上一次 ygc 过程中发生 promotion failure 时，会设置 _incremental_collection_failed为 true，即方法incremental_collection_failed()返回 true，相当于触发了 full gc。

其实不管执行 ygc 还是 full gc，都是执行 GenCollectedHeap 的do_collection()方法，最终执行CMS算法的 full gc 实现位于CMSCollector::collect()方法中，当然了，执行 full gc 的逻辑和 cms gc 不是同一条路径，只是实现在同一个文件不同方法中，而且 full gc 是单线程的，完全 stw，而cms gc 是多线程，部分过程是stw的。

还有一种情况是，当发生ygc之后，还是没有足够的内存进行分配，这时会继续触发 full gc，实现如下：

// If we reach this point, we're really out of memory. Try every trick
  // we can to reclaim memory. Force collection of soft references. Force
  // a complete compaction of the heap. Any additional methods for finding
  // free memory should be here, especially if they are expensive. If this
  // attempt fails, an OOM exception will be thrown.
  {
    IntFlagSetting flag_change(MarkSweepAlwaysCompactCount, 1); // Make sure the heap is fully compacted

    gch->do_collection(true             /* full */,
                       true             /* clear_all_soft_refs */,
                       size             /* size */,
                       is_tlab          /* is_tlab */,
                       number_of_generations() - 1 /* max_level */);
  }

concurrent model failure？

在CMS中，full gc 也叫 The foreground collector，对应的 cms gc 叫 The background collector，在真正执行 full gc 之前会判断一下 cms gc 的执行状态，如果 cms gc 正处于执行状态，调用report_concurrent_mode_interruption()方法，通知事件 concurrent mode failure，具体实现如下：

CollectorState first_state = _collectorState;
if (first_state > Idling) {
    report_concurrent_mode_interruption();
}
// 
void CMSCollector::report_concurrent_mode_interruption() {
  if (is_external_interruption()) {
    if (PrintGCDetails) {
      gclog_or_tty->print(" (concurrent mode interrupted)");
    }
  } else {
    if (PrintGCDetails) {
      gclog_or_tty->print(" (concurrent mode failure)");
    }
    _gc_tracer_cm->report_concurrent_mode_failure();
  }
}

这里可以发现是 full gc 导致了concurrent mode failure，而不是因为concurrent mode failure 错误导致触发 full gc，真正触发 full gc 的原因可能是 ygc 时发生的promotion failure。

其实这里还有concurrent mode interrupted，这是由于外部因素触发了 full gc，比如执行了System.gc()，导致了这个原因。

full gc中的compact

每次触发 full gc，会根据should_compact 标识进行判断是否需要执行 compact ，判断实现如下：

*should_compact =
    UseCMSCompactAtFullCollection &&
    ((_full_gcs_since_conc_gc >= CMSFullGCsBeforeCompaction) ||
     GCCause::is_user_requested_gc(gch->gc_cause()) ||
     gch->incremental_collection_will_fail(true /* consult_young */));

UseCMSCompactAtFullCollection默认开启，但是否要进行 compact，还得看后面的条件：
1、最近一次cms gc 以来发生 full gc 的次数_full_gcs_since_conc_gc（这个值每次执行完 cms gc 的sweeping 阶段就会设置为0）达到阈值CMSFullGCsBeforeCompaction 。(但是阈值默认为0，哪里有设置它的地方，不会每次 full gc 都是compact吧？)
2、用户强制执行了gc，如System.gc()。
3、上一次 ygc 已经失败（发生了promotion failure），或预测下一次 ygc 不会成功。

如果上述条件都不满足，是否就一直不进行 compact，这样碎片问题就得不到缓解了，幸好还有补救的机会，实现如下：

if (clear_all_soft_refs && !*should_compact) {
    // We are about to do a last ditch collection attempt
    // so it would normally make sense to do a compaction
    // to reclaim as much space as possible.
    if (CMSCompactWhenClearAllSoftRefs) {
      // Default: The rationale is that in this case either
      // we are past the final marking phase, in which case
      // we'd have to start over, or so little has been done
      // that there's little point in saving that work. Compaction
      // appears to be the sensible choice in either case.
      *should_compact = true;
    } else {
      // We have been asked to clear all soft refs, but not to
      // compact. Make sure that we aren't past the final checkpoint
      // phase, for that is where we process soft refs. If we are already
      // past that phase, we'll need to redo the refs discovery phase and
      // if necessary clear soft refs that weren't previously
      // cleared. We do so by remembering the phase in which
      // we came in, and if we are past the refs processing
      // phase, we'll choose to just redo the mark-sweep
      // collection from scratch.
      if (_collectorState > FinalMarking) {
        // We are past the refs processing phase;
        // start over and do a fresh synchronous CMS cycle
        _collectorState = Resetting; // skip to reset to start new cycle
        reset(false /* == !asynch */);
        *should_start_over = true;
      } // else we can continue a possibly ongoing current cycle
    }

普通的 full gc，参数clear_all_soft_refs为 false，不会清理软引用，如果在执行完 full gc，空间还是不足的话，会执行一次彻底的 full gc，尝试清理所有的软引用，想方设法的收集可用内存，这种情况clear_all_soft_refs为 true，而且CMSCompactWhenClearAllSoftRefs默认为 true，在垃圾收集完可以执行一次compact，如果真的走到了这一步，该好好的查查代码了，因为这次 gc 的暂停时间已经很长很长很长了。

根据对should_compact参数的判断，执行不同的算法进行 full gc，实现如下：

if (should_compact) {
    // If the collection is being acquired from the background
    // collector, there may be references on the discovered
    // references lists that have NULL referents (being those
    // that were concurrently cleared by a mutator) or
    // that are no longer active (having been enqueued concurrently
    // by the mutator).
    // Scrub the list of those references because Mark-Sweep-Compact
    // code assumes referents are not NULL and that all discovered
    // Reference objects are active.
    ref_processor()->clean_up_discovered_references();

    if (first_state > Idling) {
      save_heap_summary();
    }

    do_compaction_work(clear_all_soft_refs);

    // Has the GC time limit been exceeded?
    DefNewGeneration* young_gen = _young_gen->as_DefNewGeneration();
    size_t max_eden_size = young_gen->max_capacity() -
                           young_gen->to()->capacity() -
                           young_gen->from()->capacity();
    GenCollectedHeap* gch = GenCollectedHeap::heap();
    GCCause::Cause gc_cause = gch->gc_cause();
    size_policy()->check_gc_overhead_limit(_young_gen->used(),
                                           young_gen->eden()->used(),
                                           _cmsGen->max_capacity(),
                                           max_eden_size,
                                           full,
                                           gc_cause,
                                           gch->collector_policy());
  } else {
    do_mark_sweep_work(clear_all_soft_refs, first_state,  should_start_over);
  }

个人公众号