CMS的7个步骤
重点步骤解读
初始标记（Initial Mark）
- 目标：进行可达性分析，标记GC ROOT能直接关联到的对象。
- 标记范围：Young Gen + Old Gen。
- 线程：JDK1.7是单线程，JDK1.8是多线程
XX:+CMSParallelInitialMarkEnabled调整) 复制代码
- STW：触发Stop-The-World
- 特点：速度极快
并发标记（Concurrent Mark）
- 目标：遍历阶段1初始标记出来的存活对象，然后继续递归标记这些对象可达的对象。（黑白灰三色标记法）。
- 标记范围：Young Gen + Old Gen。
- STW：不触发
- 特点：慢，很耗时。
- 特殊操作：通过Old区卡片标记(Card Marking)，提前把老年代空间逻辑划分为相等大小的区域(Card Page)。
如果引用关系发生改变，JVM会将发生改变的区域标记位“脏区”(Dirty Card)。
JVM会对“并发标记”阶段应用线程新产生的对象及对象涉及的引用修改做记录（Mod-Union Table）
预清理（Preclean）
- 目标：并发标记阶段中记录在（Mod-Union Table）的这些脏区会被找出来，刷新引用关系，清除“脏区”标记。
- 标记范围： Old Gen。
- 线程：GC线程和应用线程也是并发执行
- STW：不触发
- 特点：速度一般
可中断的预清理(Concurrent Abortable Preclean)
- 目标：降低垃圾回收时对应用的暂停时间，整个过程最耗时步骤在5(最终/重新标记)，所以4步骤提前进行。
- 触发条件：此阶段在Eden区使用超过2M时启动，当然2M是默认的阈值，可以通过参数修改。
- 标记范围：Young Gen + Old Gen。
- 处理From、To区对象，标记可达到老年代的对象。和3阶段一样，扫描处理Dirty Card中的对象。
- 终止逻辑：CMS为了避免这个阶段没有等到Minor GC而陷入无限等待，提供了参数CMSMaxAbortablePrecleanTime ，默认为5s；含义是如果可中断的预清理执行超过5s，不管发没发生Minor GC，都会中止此阶段，进入Remark，以及eden去内存容量占比的空间阈值等。
- 线程：GC线程和应用线程也是并发执行。
- STW：不触发
- 特点：速度一般
- 特殊：下一个阶段要执行最耗时且STW的Remark阶段，Remark阶段会将整个YoungGen作为GC-Root进行操作，如果4阶段能触发一次MonitorGC就再好不过了。
重新标记（Final ReMark）
- 目标：GC事件中第二次(也是最后一次)STW阶段，目的是完成老年代中所有存活对象的标记。
- 标记范围：Young Gen + Old Gen。
- 线程：GC线程独占执行
- STW：触发Stop-The-World
- 特点：速度较慢，可以说是整个CMS-Old GC的瓶颈点。
特殊：
- 遍历新生代对象，重新标记
- 根据GC Roots，重新标记
- 遍历老年代的Dirty Card，重新标记
并发清除(Concurrent Sweep)
- 目标：根据标记结果清除垃圾对象。
- 标记范围：Old Gen。
- 线程：GC线程和应用线程也是并发执行
- STW：不触发
- 特点：速度一般。
并发重置(Concurrent Reset)
- 目标：重置CMS算法相关的内部数据, 为下一次GC循环做准备。
- 线程：GC线程和应用线程也是并发执行
- STW：不触发
- 特点：速度一般。
CMS相关常见问题总结
- CMS回收第一阶段“初始标记”都标记哪些？STW嘛？
初始标记需要STW，为了保障低停顿，只标记出GC-ROOT直接引用的对象。
- CMS回收第二阶段“并发标记”都标记哪些？STW嘛？
并发标记不会STW，垃圾回收线程与工作线程同时工作。并发标记时根据第一阶段标记的GC-ROOT进行延展标记。
- CMS回收第三阶段“重新标记”都标记哪些？STW嘛？
重新标记需要STW，需要标记第二阶段新创建对象&已有对象可能失去引用变成垃圾。
- CMS回收第四阶段“并发清理”会STW嘛?
并发清理很耗时，需要进行对象清理，垃圾回收线程与工作线程并发运行的，不会STW，可能会产生浮动对象产生1。
- CMS回收“并发标记”&“并发清理”这两个阶段时，垃圾回收线程与工作线程并行运行，会导致cpu资源会成为瓶颈，CMS并发回收线程数如何设置？
cms默认启动的垃圾回收线程数：（cpu核数+3）/4
- CMS回收器在“并发清理”阶段可能会发生
“Concurrent Mode Failure”问题？为什么？发生了“Concurrent Mode Failure”问题jvm会如何解决
CMS在“并发清理”阶段系统线程是工作着的，这就会产生“浮动垃圾”（通过YoungGC进入老年代的对象），CMS为了保证回收期间还有一定的内存空间让一些对象进入老年代，一半会预留一些空间，
-XX:CMSInitiatingOccupancyFraction设置剩余百分比（默认68%），1.8以后变成了92%。
- 如果CMS在回收期间，剩余空间小于本次晋升的对象大小会怎样呢？
就会发生
“Concurrent Mode Failure”错误，也就是说并发垃圾回收失败，此时JVM会升级处理策略：自动启用“Serial Old”垃圾回收替代CMS回收，Serial Old 会强行STW，重新进行GC-Roots跟踪标记出全部垃圾对象，不允许新对象产生，一次性清理垃圾对象，然后恢复系统线程。
- CMS内存碎片整理会STW嘛？为什么？
首先内存整理会STW，内存碎片会导致分配连续空间受阻，JVM就会频繁触发FullGC。所以CMS也会根据设置
-XX:CMSFullGCsBeforeCompaction=n意思是说在上一次CMS并发GC执行过后，到底还要再执行多少次full GC才会做压缩。
- 默认是0，就是在默认配置下每次CMS GC顶不住了而要转入full GC的时候都会做压缩。
- 如果把CMSFullGCsBeforeCompaction配置为10，就会让上面说的第一个条件变成每隔10次真正的full GC才做一次压缩。
- 有几种情况会触发老年代执行GC？
- 老年代可用空间小于新生代全部对象的大小，如果没有开启空间担保策略会执行FullGC，一般默认担保策略是打开的。
- 历次新生代GC后进入老年代的平均大小大于老年代可用空间。
- 老年代使用空间大于
-XX:CMSInitiatingOccupancyFraction设置的阀值。
- 什么是分配担保？默认开启嘛？可以去掉分配担保机制吗？为什么需要的是连续空间？
- 在发生Minor GC时候，虚拟机会检查老年代最大可用的连续空间是否大于新生代所有对象的总空间。
- 如果大于，则此次Minor GC是安全的。
- 如果小于，则虚拟机会查看HandlePromotionFailure设置分配担保。
HandlePromotionFailure=true，and 老年代最大可用连续空间是否大于历次晋升到老年代的对象的平均大小，如果大于，则尝试进行一次Minor GC。
HandlePromotionFailure=falseor 老年代最大可用连续空间小于历次晋升到老年代的对象的平均大小，执行FullGC。
1.6以后是默认开启的。可以去掉，会加大FullGC发生的概率。虚拟机短暂停止，吞吐量、性能下降。新生代使用的是复制算法，复制算法决定需要连续空间。
