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

[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。