这是一种以最短回收停顿时间为目标的收集器
适合应用在互联网或者B/S系统的服务器上，这类应用尤其重视服务器的响应速度，希望系统停顿时间最短。
CMS非常适合堆内存大，CPU核数多的服务器端应用，也是G1出现之前大型应用的首选收集器 |
| | 优点：并发收集低停顿
缺点：并发执行，对CPU资源压力大，采用的标记清除算法会导致大量碎片
由于并发进行，CMS在收集与应用线程会同时增加对堆内存的占用，也就是说，CMS必须在老年代堆内存用尽之前完成垃圾回收，否则CMS回收失败时，将触发担保机制，串行老年代收集器将会以STW方式进行一次GC，从而造成较大的停顿时间
CMS无法整理空间碎片，老年代空间会随着应用时长被逐步耗尽，最后将不得不通过担保机制对堆内存进行压缩，CMS也提供了参数 -XX:CMSFullGCSBeForeCompaction（默认0，即每次都进行内存整理）来指定多少次CMS收集之后，进行一次压缩的Full GC | 四个步骤
- 初始标记（CMS initial mark）
- 只是标记一个GC Roots 能直接关联的对象，速度很快，仍然需要暂停所有的工作线程
并发标记（CMS concurrent mark）和用户线程一起
- 进行GC Roots跟踪过程，和用户线程一起工作，不需要暂停工作线程。主要标记过程，标记全部对象
重新标记（CMS remark）
- 为了修正在并发标记期间，因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，仍然需要暂停所有的工作线程，由于并发标记时，用户线程依然运行，因此在正式清理前，在做修正
并发清除（CMS concurrent sweep）和用户线程一起
- 清除GC Roots不可达对象，和用户线程一起工作，不需要暂停工作线程。基于标记结果，直接清理对象，由于耗时最长的并发标记和并发清除过程中，垃圾收集线程可以和用户现在一起并发工作，所以总体上来看CMS收集器的内存回收和用户线程是一起并发地执行。
|
|
G1垃圾回收器
JDK9默认 | G1垃圾回收器将堆内存分割成不同区域，然后并发的进行垃圾回收 |
| ZGC垃圾回收器
JDK11默认 | zgc是为大内存、多cpu而生，它通过分区的思路来降低STW，比如原来我有一个巨大的房间需要打扫卫生，每打扫一次就需要很长时间的STW，因为房间太大了，后来我改变了思路，把这个巨大的房间打隔断，最终出来100个小房间，这些小房间可以是eden区、可以是s区、也可以是old区，没有固定，每次只选择最需要打扫的房间(垃圾最多的)进行打扫，最终把这个房间的存活对象转移到其它房间，同时其它房间还可以继续供客户使用，也就是并行、并发的打扫，只在某几个必须的阶段进行很短暂的STW，其它时间都是和用户线程并行工作，这样可以很好的控制STW时间，同时也因为占用了很多cpu时间并发干活导致吞吐量降低，所以如果硬件充足的情况下 可以考虑 ZGC。 | | 默认垃圾回收器
使用下面JVM命令，查看配置的初始参数
-XX:+PrintCommandLineFlags