为什么CMS收集器在初始标记阶段收集年轻一代的根引用？

Question

据我所知，CMS collector收集老一代，它与ParNew collector（用于收集年轻一代）一起工作。对我来说，要清楚地理解CMS是如何工作的并不容易，但以下是我的看法：

1）初始标记。寻找根引用。由于收集器是旧的收集器，它应该只扫描旧的一代。

2） 并发标记找到所有根引用后，是时候开始并发标记了。从第一阶段中标记的对象可传递到达的所有对象都在该阶段中标记。

3） 并发预清理gc查看CMS堆中的对象，这些对象是通过年轻一代的升级或新分配更新的，或者是在我们在上一个并发标记阶段进行并发标记时通过变异程序更新的。【请确认1本阶段的唯一目的是完成下一阶段必须完成的部分工作（备注）？2）有一些程序正在查看在并发标记阶段更改了哪些参考。请告诉我这两项是否正确】

4） 备注：gc停止运行，然后查看CMS堆中的对象，这些对象是通过年轻一代的升级或新分配更新的，或者是在我们进行并行预清理时通过变体更新的。

但今天我看到了这篇文章

初始标记在初始标记期间，CMS应收集所有根引用，以开始标记旧空间。这包括：来自线程堆栈的引用，来自young space的引用。从堆栈中收集引用通常非常快（小于1ms），但从年轻空间收集引用的时间取决于年轻空间中对象的大小。通常初始标记在年轻的空间收集之后立即开始，所以伊甸园空间是空的，只有活的对象在幸存者空间中。幸存者空间通常很小，年轻空间收集后的初始标记通常不到毫秒。但如果最初的标记是在伊甸园满的时候开始的，可能需要相当长的时间（通常比年轻的空间收藏本身要长）。一旦触发CMS收集，JVM可能会等待一段时间，等待年轻的收集发生，然后才开始初始标记。JVM配置选项–XX:CMSWaitDuration=可用于设置CMS在开始初始标记之前等待年轻空间收集的时间。如果希望避免长时间的初始标记暂停，则应将此时间配置为比应用程序中典型的年轻集合时间长。

备注：大多数标记与应用程序并行进行，但可能不准确，因为应用程序可能会在标记期间修改对象图。同时标记完成时；垃圾收集器应该停止应用程序并重复标记，以确保所有可访问的对象都标记为活动对象。但收集器不必遍历整个对象图；它应该只遍历自标记开始（实际上是自预清洁阶段开始）以来修改的参考。Card table（参见Card marking write barrier）用于识别旧空间中内存的修改部分，但应再次扫描线程堆栈和新空间。通常，评论阶段的大部分时间都用来扫描年轻的空间。如果我们在开始评论之前在年轻的空间收集垃圾，这个时间会短得多。我们可以指示JVM总是在CMS评论之前强制年轻的空间收集。使用JVM参数–XX:CMSScavengeBeforeRemark启用此选项。即使年轻的空间是空的，备注阶段仍然必须扫描旧空间中修改过的引用，这通常需要接近正常年轻收集暂停的时间（年轻收集期间对旧空间的扫描与备注所需的扫描类似）。

http://blog.griddynamics.com/2011/06/understanding-gc-pauses-in-jvm-hotspots_02.html

我不明白为什么CMS需要扫描年轻一代。为什么旧一代的垃圾收集需要它？

Answer 1

Java堆被分成独立收集的两部分：旧空间和年轻空间。

要收集任何一个空间，您需要找到空间之外的所有入站引用。他们是：

• 堆栈中的局部变量
• 嵌入到JIT编译代码块中的文字
• 来自另一个空间的所有引用

旧的收藏应该扫描年轻的空间，而年轻的收藏应该扫描旧的空间，两者没有区别。

卡片表写屏障用于不扫描每个年轻集合的整个旧空间（只有一小部分旧空间包含指向年轻的链接，写屏障有助于跟踪该区域）。

但年轻的空间没有卡片桌，所以旧的收藏应该扫描整个存储范围。

PS我是你参考过的文章的作者，你可以在我的博客上找到更多GC相关的文章

Answer 2

你可能有循环引用的类，比如a类有对B类的引用，B类有对a的反向引用。如果你有属于这些类的对象a和B，并且相互引用，gc必须在你从“外部”删除对它们的最后一个引用时删除它们。当然，如果引用循环包含更多元素，情况可能会复杂得多。所以gc必须检查哪些元素可以从某个根访问，哪些元素被引用，但不可访问，并且应该被收集。

现在，如果你有，在你的代码中的某个地方

Object a=new A(new B(new C(new D())))

构造函数可能需要一段时间才能分配一个。但是你不希望gc删除新创建的D，仅仅因为C的构造函数需要一段时间才能运行，而且a还没有被分配。因此，您还需要扫描年轻的一代，以捕获太年轻而无法从堆中引用的对象。