为什么Java8不使用CMS作为默认垃圾收集器

一般的垃圾回收器搭配为：

Serial New（复制算法。单线程） + Serial Old（标记整理。单线程） (Serial系列是单线程，GC时stop the world) 
ParNew（复制算法。并行。除了多线程跟Serial差不多，单核情况下不如Serial） + CMS（标记清除。并发） + Serial Old
Parallel Scavenge（复制算法。并行） + Parallel Old（标记整理。并行）
G1 
shenandoah
zgc

上面的并发和并行是指：
并行：指多条垃圾回收线程并行工作，但此时用户线程仍处于等待状态
并发：指用户线程与垃圾回收线程同时执行（但并不一定是并行的，可能会交替执行），用户程序在继续执行，而垃圾收集程序运行在另一个cpu上。

历代版本的默认收集器始终没有使用CMS作为默认收集器，在jdk9 G1成为default gc策略之后，CMS就被deprecated，然后在14被正式从jdk中删除。Java官方做出这样的决定肯定是有原因的，虽然CMS相比Parallel是后推出的收集器，但并不意味CMS综合来看比Parallel强。

CMS是关注低延迟的收集器（以获取最短回收停顿时间为目标的收集器），Parallel是关注高吞吐量（吞吐量=运行用户代码时间 / 运行用户代码时间 + 垃圾收集时间）的收集器，在一般的服务端中大型系统中，高吞吐量仍然是很多程序追求的重点，况且Linux和网络本身就就会有停顿，造成延迟的效果。

1. CMS在GC时会对CPU有比较大的压力，形成典型的CPU Spike。

2. CMS仅针对老年代，还需要一个年轻代的收集器。

3. CMS和Parallel Scavenge不兼容，只能和ParNew凑合，然而ParNew又不如Parallel Scavenge先进。

4. CMS没法处理浮动垃圾，并发标记过程中死亡的对象只能留到以后的GC处理。

5. Mark-Sweep算法对内存碎片无能为力，并发又如何？内存碎片太多，触发了Concurrent Mode Failure还不是得去请Serial Old来收拾烂摊子？结果就是stop the world。

…以上的种种，造成的结果就是ParNew+CMS+Serial Old的组合工作起来其实并不稳定。为了得到CMS那一点好处，需要付出很多的代价（包括JVM调参）。所以作为默认GC，采用Parallel Scavenge/Parallel Old这种省心又省力方案完全合理。况且之后出现的G1收集器无需复杂的配置即可达到很高的综合性能（停顿时间可控，默认200ms，更少的FullGC次数），CMS就更没必要了。

参考：https://www.zhihu.com/question/418331009