CMS垃圾回收器详解
CMS垃圾回收器
CMS垃圾回收器
如果用Seria和Parallel系列的垃圾收集器：在垃圾回收的时，用户线程都会完全停止，直至垃圾回收结束！
CMS的全称：Concurrent Mark Sweep，翻译过来是并发标记清除
用CMS对比上面的垃圾收集器(Seria和Parallel和parNew)：它最大的不同点就是并发：在GC线程工作的时候，用户线程不会完全停止，用户线程在部分场景下与GC线程一起并发执行。
但是，要理解的是，无论是什么垃圾收集器，Stop The World是一定无法避免的！
CMS只是在部分的GC场景下可以让GC线程与用户线程并发执行
CMS的设计目标是为了避免老年代 GC出现长时间的卡顿（Stop The World）
CMS的工作流程
CMS可以简单分为5个步骤：初始标记、并发标记、（并发预清理）、重新标记以及并发清除
从步骤就不难看出，CMS主要是实现了标记清除垃圾回收算法
初始标记的过程
初始标记会标记GCRoots直接关联的对象以及年轻代指向老年代的对象
初始标记这个过程是会发生Stop The World的。但这个阶段的速度算是很快的，因为没有向下追溯（只标记一层）
并发标记的过程
在初始标记完了之后，就进入了并发标记阶段啦
并发标记这个过程是不会停止用户线程的（不会发生 Stop The World）。这一阶段主要是从GC Roots向下追溯，标记所有可达的对象。
并发标记在GC的角度而言，是比较耗费时间的（需要追溯）
并发标记这个阶段完成之后，就到了并发预处理阶段啦
并发预处理这个阶段主要想干的事情：希望能减少下一个阶段重新标记所消耗的时间
因为下一个阶段重新标记是需要Stop The World的
并发标记这个阶段由于用户线程是没有被挂起的，所以对象是有可能发生变化的
可能有些对象，从新生代晋升到了老年代。可能有些对象，直接分配到了老年代（大对象）。可能老年代或者新生代的对象引用发生了变化…
跨代引用的问题
针对老年代的对象，其实还是可以借助类card table的存储（将老年代对象发生变化所对应的卡页标记为dirty）
所以并发预处理这个阶段会扫描可能由于并发标记时导致老年代发生变化的对象，会再扫描一遍标记为dirty的卡页
对于新生代的对象，我们还是得遍历新生代来看看在并发标记过程中有没有对象引用了老年代..
不过JVM里给我们提供了很多参数，有可能在这个过程中会触发一次 minor GC（触发了minor GC 是意味着就可以更少地遍历新生代的对象）
重新标记的过程
并发预处理这个阶段阶段结束后，就到了重新标记阶段
重新标记阶段会Stop The World，这个过程的停顿时间其实很大程度上取决于上面并发预处理阶段（可以发现，这是一个追赶的过程：一边在标记存活对象，一边用户线程在执行产生垃圾）
并发清除的过程
最后就是并发清除阶段，不会Stop The World
一边用户线程在执行，一边GC线程在回收不可达的对象
这个过程，还是有可能用户线程在不断产生垃圾，但只能留到下一次GC 进行处理了，产生的这些垃圾被叫做“浮动垃圾”
完了以后会重置 CMS 算法相关的内部数据，为下一次 GC 循环做准备
CMS的缺点
- 空间需要预留：CMS垃圾收集器可以一边回收垃圾，一边处理用户线程，那需要在这个过程中保证有充足的内存空间供用户使用。如果CMS运行过程中预留的空间不够用了，会报错（Concurrent Mode Failure），这时会启动 Serial Old垃圾收集器进行老年代的垃圾回收，会导致停顿的时间很长。显然啦，空间预留多少，肯定是有参数配置的。
- 浮动垃圾：由于垃圾回收和用户线程是同时进行的，在进行标记或者清除的同时，用户的线程还会去改变对象的引用，使得原来某些对象不是垃圾，但是当 CMS 进行清理的时候变成了垃圾，CMS 收集器无法收集，只能等到下一次 GC。CMS 收集器无法处理浮动垃圾（Floating Garbage），可能出现 “Concurrent Mode Failure” 失败而导致另一次 Full GC 的产生。如果在应用中老年代增长不是太快，可以适当调高参数 - XX:CMSInitiatingOccupancyFraction 的值来提高触发百分比，以便降低内存回收次数从而获取更好的性能。
- 内存碎片问题：CMS本质上是实现了标记清除算法的收集器（从过程就可以看得出），这会意味着会产生内存碎片。由于碎片太多，又可能会导致内存空间不足所触发full GC，CMS一般会在触发full GC这个过程对碎片进行整理。整理涉及到移动/标记，那这个过程肯定会Stop The World的，如果内存足够大（意味着可能装载的对象足够多），那这个过程卡顿也是需要一定的时间的。
