了解了这么多有关Java的收集器，不知道是否了解CMS垃圾收集器呢?不了解的今天可以跟着小编一起来学习，了解的可以跟着小编复习巩固知识哦。
CMS是老年代垃圾收集器，在收集过程中可以与用户线程并发操作。
它可以与Serial收集器和Parallel New收集器搭配使用。CMS牺牲了系统的吞吐量来追求收集速度，适合追求垃圾收集速度的服务器上。可以通过JVM启动参数：-XX:+UseConcMarkSweepGC来开启CMS。
CMS 处理过程七个步骤如下：
1. 初始标记(CMS-initial-mark) ,会导致stw;
2. 并发标记(CMS-concurrent-mark)，与用户线程同时运行;
3. 预清理(CMS-concurrent-preclean)，与用户线程同时运行;
4. 可被终止的预清理(CMS-concurrent-abortable-preclean) 与用户线程同时运行;
5. 重新标记(CMS-remark) ，会导致swt;
6. 并发清除(CMS-concurrent-sweep)，与用户线程同时运行;
7. 并发重置状态等待下次CMS的触发(CMS-concurrent-reset)，与用户线程同时运行
特点
针对老年代;
基于"标记-清除"算法(不进行压缩操作，产生内存碎片);
以获取最短回收停顿时间为目标;
并发收集、低停顿;
需要更多的内存(看后面的缺点)
是HotSpot在JDK1.5推出的第一款真正意义上的并发(Concurrent)收集器;
第一次实现了让垃圾收集线程与用户线程(基本上)同时工作;
CMS收集器3个明显的缺点
1. 对CPU资源非常敏感
并发收集虽然不会暂停用户线程，但因为占用一部分CPU资源，还是会导致应用程序变慢，总吞吐量降低。
增量式并发收集器：
针对这种情况，曾出现了"增量式并发收集器"(Incremental Concurrent Mark Sweep/i-CMS);
2.无法处理浮动垃圾,可能出现"Concurrent Mode Failure"失败
(1)、浮动垃圾(Floating Garbage)
在并发标记时，用户线程新产生的垃圾，称为浮动垃圾;
所谓的“浮动垃圾”，就是在并发标记阶段，由于用户程序在运行，那么自然就会有新的垃圾产生，这部分垃圾被标记过后，CMS无法在当次集中处理它们(为什么?原因在于CMS是以获取最短停顿时间为目标的，自然不可能在一次垃圾处理过程中花费太多时间)，只好在下一次GC的时候处理。这部分未处理的垃圾就称为“浮动垃圾
(2)、"Concurrent Mode Failure"失败
如果CMS预留内存空间无法满足程序需要，就会出现一次"Concurrent Mode Failure"失败
3、产生大量内存碎片
由于CMS基于"标记-清除"算法，清除后不进行压缩操作;
产生大量不连续的内存碎片会导致分配大内存对象时，无法找到足够的连续内存，从而需要提前触发另一次Full GC动作。
以上就是今天所讲的有关java架构师的知识，如果想要了解更多，请继续关注本网站。