CMS垃圾回收

内存分代

算法

标记-清除

特点

并发收集器，以最短的停顿时间为目标的收集器

不足

1. 对CPU资源敏感，GC线程占用CPU资源高影响吞吐量
2. 需要预留一些空间，保证触发后台垃圾回收而不是fullgc
3. 标记-清除会产生内存碎片，虽然可以设置执行多少次不压缩的GC来一次压缩的GC，但是由于整理过程无法并发所以这时停顿时间会较长

回收过程

1. 初始标记(STW)

标记与GCRoots直接关联的对象

2. 并发标记

1. 对上一步标记进行trace标记可达
2. 并且在此阶段新生代晋升带老年代的card在cardTable中标记为dirty

3. 并发预清理

处理并发阶段新晋升的或者被修更新的老年带对象，减少重标记的工作量

4. 重新标记(STW)

进行可达性分析，重新标记活着的对象。因为之前的步骤这步时间会大大减少

5. 并发清除

清理无效对象

6. 重置

CMS清除内部状态，为下次回收做准备

---

垃圾回收模式：

1. background collector:

1. 未开启UseCMSInitiatingOccupancyOnly时，虚拟机会自行决定是否触发
2. 老年代使用率达到阈值 CMSInitiatingOccupancyFraction，配置了UseCMSInitiatingOccupancyOnly
3. 永久代的使用率达到阈值 CMSInitiatingPermOccupancyFraction，并开启 CMSClassUnloadingEnabled并且配置了UseCMSInitiatingOccupancyOnly
4. 调用System.gc()并且设置了-XX:+ExplicitGCInvokesConcurrent

2. foreground collector:(前台收集器在1.8中已经废弃了这种模式)

1. concurrent mode failure，CMS会根据UseCMSCompactAtFullCollection、CMSFullGCsBeforeCompaction得值判断是否使用foreground collector或者fullgc（这里次数是foreground collector 的次数）

3. Full Gc:

1. 使用跟Serial Old GC一样的LISP2算法的mark-compact来做full GC
2. promotion failed会引发

参考：
1.CMS参数
2.CMS回收模式
3.CMS重标记