第3章3.5.6CMS收集器有些疑问

[sparkler-deng]

疑问一：当出现“Concurrent Mode Failure”失败时，导致另一次完全“Stop The World”的Full GC的产生。这时候虚拟机不得不启动后备预案：冻结用户线程执行，临时启用Serial Old收集器来重新进行老年代的垃圾收集。

1.书中77页的“注意”中统一定义：整堆收集（Full GC）。这里启用Serial Old收集，也只是收集老年代，不应该Full GC吧？
2.猜想：启用Serial Old收集，也会触发新生代的收集？
3.书中77页的“注意”中统一定义：老年代收集的内容中指出“目前只有CMS收集器会有单独收集老年代的行为”。这句好像印证了上面的猜想：启用Serial Old收集，也会触发新生代的收集。
4.如果猜想正确，不明白为什么是这样，因为新生代的收集对老年代似乎启不到作用。

疑问二：CMS基于“标记-清除”算法收集时，由于碎片过多，导致无法给大对象分配，而不得不提前触发一次Full GC。

1.这里的提前触发，使用的应该还是CMS收集器，“目前只有CMS收集器会有单独收集老年代的行为”，这里的Full GC表述是不是有误？应该是老年代收集（Major GC）。
2.但参数：-XX:CMSFullGCsBeforeCompaction中的FullGCs也是把对老年代的收集称为Full GC，那这样又与77页的Full GC定义冲突。

感谢你在百忙之中抽出时间，期待你的回复。

谢谢，祝一切顺利~

[fenixsoft]

是的，在Concurrent Mode Failure的发生的时候，会触发整堆范围内的收集。

要解释您第4点的疑问，要先理解为什会发生“Concurrent Mode Failure”：简要的说，是此时CMS已经处于老年代的收集过程中，由于CMS的收集与用户程序是并发进行的，此时随着程序运行新对象仍然在持续产生，当CMS收集速度赶不上新对象进入老年代的速度，预留的老年代空间被消耗殆尽后，就不得不停下来启用串行FullGC的后备预案，这个行为即为“Concurrent Mode Failure”。

请注意到对象通常不会直接在老年代中分配，而是随着新生代收集过程中晋升而来到老年代的，当老年代没有足够空间可以安置晋升对象时，通常意味着对应着一次新生代的收集也没有顺利地正常完成，而不仅是老年代失败。所以，出现Concurrent Mode Failure时，进行覆盖新生代、老年代的全堆FullGC是合理的。

顺便提一下，您的第2点猜想“启用Serial Old收集，也会触发新生代的收集”：如上面所说，触发新生代收集是Concurrent Mode Failure自身所需，而与采用Serial Old作为后备预案并无直接关系。事实上，CMS采用Serial Old而非其他跟先进一些的收集器做后备主要是工作量最小化角度考虑的，有一些OpenJDK的改进版（譬如Alibaba JDK Dragonwell）中是实现了并行收集作为CMS的后备的，此时同样会触发全堆收集。

关于疑问二：这里说的Full GC，仍然是指全堆的收集。尽管此场景下，导致无法分配新的大对象确实只限于老年代，与新生代无关。但HotSpot中的只有CMS有单独收集老年代的行为，它是sweep base的收集器，不能处理空间碎片，当它借用其他compact base的收集器时，就不再会维持单独收集老年代的行为，所以这里使用FullGC的描述是妥当的。

[sparkler-deng]

非常感谢，解答的这么及时，并且非常详尽的，完全解答了我心中的疑惑，豁然开朗。

再说下题外话，你现在这个github地址有点不好找。
我先是发gmail邮件不成功，然后翻第2版的勘误里注的iteye博客，再找到微博，感觉都不是正确的地方。后来google“icyfenix”关键字，搜到了豆瓣，再标注时间为2011的留言里发现“第三版最新的勘误地址github”...

期间差点就算了。一怕发的位置不对，大佬可能注意不到；二怕大佬太忙，我的问题太浅薄...
总之，最后找到了，得到了详尽及时的解答，这真是非常非常非常值得的。

PS:建议在你的iteye，豆瓣显眼的位置标下第三版的github。