CMS垃圾收集器

CMS垃圾收集器深入解析：

CMS回收流程

官网： https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/cms.html#concurrent_mark_sweep_cms_collector

CMS(Concurrent Mark Sweep)收集器是一种以获取 最短回收停顿时间为目标的收集器。不关心垃圾碎片的产生

采用的是"标记-清除算法",整个过程分为4步

(1)初始标记 CMS initial mark     标记GC Roots直接关联对象，不用Tracing，速度很快
(2)并发标记 CMS concurrent mark  进行GC Roots Tracing
(3)重新标记 CMS remark           修改并发标记因用户程序变动的内容
(4)并发清除 CMS concurrent sweep 清除不可达对象回收空间，同时有新垃圾产生，留着下次清理称为浮动垃圾

由于整个过程中，并发标记和并发清除，收集器线程可以与用户线程一起工作，所以总体上来说，CMS收集器的内存回收过程是与用户线程一起并发地执行的。

优点：并发收集、低停顿
缺点：产生大量空间碎片、并发阶段会降低吞吐量

第一个问题：为什么我的CMS回收流程图上初始标记是单线程，为什么不使用多线程呢？

初始化标记阶段是串行的，这是JDK7的行为。JDK8以后默认是并行的，可以通过参数

-XX:+CMSParallelInitialMarkEnabled控制

CMS的两种模式与一种特殊策略：

Backgroud CMS ：

实际上我们的并发标记还能被整理成两个流程

(1)初始标记
(2)并发标记
(3)并发预处理
(4)可中止的预处理
(5)重新标记
(6)并发清除

为什么我们的并发标记细化之后还会额外有两个流程出现呢？

讨论这个问题之前，我们先思考一个问题，假设CMS要进行老年代的垃圾回收，我们如何判断被年轻代的对象引用的老年代对象是可达对象。

也就是这张图，当老年代被回收的时候，我们如何判断A对象是存活对象。

答：必须扫描新生代来确定，所以CMS虽然是老年代的垃圾回收器，却需要扫描新生代的原因。

问题2：既然这个时候我需要扫描新生代，那么全量扫描会不会很慢

答：肯定会的 ，但是接踵而来的问题：既然会很慢，我们的停顿时间很长，可是CMS的目标是什么

CMS(Concurrent Mark Sweep)收集器是一种以获取 最短回收停顿时间为目标的收集器。这不是与他的设计理念不一致吗？

思考：怎么让我们的回收变快

答：肯定是垃圾越少越快。所以我们的CMS想到了一种方式，就是我先进行新生代的垃圾回收，也就是一次young GC，回收完毕之后。是不是我们新生代的对象就变少了，那么我再进行垃圾回收，是不是就变快了。

所以，CMS有两个参数：

CMSScheduleRemarkEdenSizeThreshold 默认值：2M

CMSScheduleRemarkEdenPenetration 默认值：50%

这两个参数组合起来就是预清理之后，Eden空间使用超过2M的时候启动可中断的并发预清理（CMS-concurrent-abortable-preclean），到Eden空间使用率到达50%的时候中断（但不是结束），进入Remark（重新标记阶段）。

这里面有个概念，老师，为什么并发预处理前面会有可中断几个字呢？什么意思。

可中断意味着，假设你一直在预处理，预处理是干什么，无非就是去帮你把正式应该处理的前置工作给做了。所以他一定干了很多事情，但是这些事情迟早有个头，所以就设置了一个时间对他进行打断。所以，并发预处理的逻辑是当你发生了minor GC ，我就预处理结束了。

这里有个问题，我怎么知道你什么时候发生minor GC

答：答案是我不知道，垃圾回收是JVM自动调度的，所以我们无法控制垃圾回收。

那我不可能无限制的执行下去，总要有个结束时间吧

CMS提供了一个参数CMSMaxAbortablePrecleanTime