CMS垃圾收集器详解

CMS垃圾回收特点

CMS(Concurrent Mark Sweep)只回收老年代和永久代（jdk 1.8开始为元数据区，需要设置CMSClassUnloadingEnabled），不会收集年轻代；

CMS是一种预处理垃圾回收器，它不能等到老年代内存用尽时回收，需要在内存用尽前，完成回收操作，否则会导致并发回收失败；所以CMS垃圾回收器开始执行回收操作，有一个触发阈值，默认是老年代或永久代达到92%。

1、CMS垃圾回收器工作原理

CMS 处理过程有七个步骤：

1. 初始标记(CMS-initial-mark) ,会导致swt；

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)，与用户线程同时运行；

CMS运行流程图如下所示：

初始标记

这是CMS中两次stop-the-world事件中的一次。这一步的作用是标记存活的对象，有两部分：

1. 标记老年代中所有的GC Roots对象，如下图节点1；

2. 标记年轻代中活着的对象引用到的老年代的对象（指的是年轻代中还存活的引用类型对象，引用指向老年代中的对象）如下图节点2、3。

在Java语言里，可作为GC Roots对象的包括如下几种：

1. 虚拟机栈(栈桢中的本地变量表)中引用的对象 ；

2. 方法区中的类静态属性引用的对象 ；

3. 方法区中的常量引用的对象 ；

4. 本地方法栈中JNI的引用的对象；

ps：为了加快此阶段处理速度，减少停顿时间，可以开启初始标记并行化，-XX:+CMSParallelInitialMarkEnabled，同时调大并行标记的线程数，线程数不要超过cpu的核数。

并发标记

从“初始标记”阶段标记的对象开始找出所有存活的对象。

因为是并发运行的，在运行期间会发生新生代的对象晋升到老年代、或者是直接在老年代分配对象、或者更新老年代对象的引用关系等等，对于这些对象，都是需要进行重新标记的，否则有些对象就会被遗漏，发生漏标的情况。为了提高重新标记的效率，该阶段会把上述对象所在的Card标识为Dirty，后续只需扫描这些Dirty Card的对象，避免扫描整个老年代。

并发标记阶段只负责将引用发生改变的Card标记为Dirty状态，不负责处理。

如下图所示，也就是节点1、2、3，最终找到了节点4和5。并发标记的特点是GC线程和应用程序线程同时运行。并不是老年代的所有存活对象都会被标记，因为标记的同时应用程序会改变一些对象的引用等。

这个阶段因为是并发的，容易导致concurrent mode failure。

预清理阶段

前一个阶段已经说明，不能标记出老年代全部的存活对象，是因为标记的同时应用程序会改变一些对象引用，这个阶段就是用来处理前一个阶段因为引用关系改变导致没有标记到的存活对象的，它会扫描所有标记为Dirty的Card。

如下图所示，在并发清理阶段，节点3的引用指向了6，则会把节点3的card标记为Dirty。

最后将6标记为存活，如下图所示：

可终止的预处理

这个阶段尝试着去承担下一个阶段Final Remark阶段足够多的工作。这个阶段持续的时间依赖好多的因素，由于这个阶段是重复的做相同的事情直到发生aboart的条件（比如：重复的次数、多少量的工作、持续的时间等等）之一才会停止。

ps:此阶段最大持续时间为5秒，之所以可以持续5秒，另外一个原因也是为了期待这5秒内能够发生一次ygc(年轻代垃圾收集)，清理年轻代的引用，为了使下个阶段(重新标记阶段)扫描年轻代指向老年代引用的时间减少。

重新标记

这个阶段会导致第二次stop the word，该阶段的任务是标记整个老年代的所有存活对象。

这个阶段，重新标记的内存范围是整个堆，包含_young_gen和_old_gen。为什么要扫描新生代呢，因为对于老年代中的对象，如果被新生代中的对象引用，那么就会被视为存活对象，即使新生代的对象已经不可达了，也会使用这些不可达的对象当做CMS的“gc root”来扫描老年代。因此对于老年代来说，引用了老年代中对象的新生代对象，也会被老年代视作“GC ROOTS”。当此阶段耗时较长的时候，可以加入参数-XX:+CMSScavengeBeforeRemark，在重新标记之前，先执行一次ygc，回收掉年轻代中无用的对象，并将对象放入幸存区或晋升到老年代，这样再进行年轻代扫描时，只需要扫描幸存区的对象即可，一般幸存区非常小，这大大减少了扫描时间。

由于之前的预处理阶段是与用户线程并发执行的，这时候可能年轻代的对象对老年代的引用已经发生了很多改变，这个时候，remark阶段要花很多时间处理这些改变，会导致很长stop the word，所以通常CMS运行Final Remark阶段尽量是在年轻代足够干净的时候。

另外，还可以开启并行收集：-XX:+CMSParallelRemarkEnabled。

并发清理

通过以上5个阶段的标记，老年代所有存活的对象已经被标记并且现在要通过Garbage Collector采用清扫的方式回收那些不能用的对象了。 这个阶段主要是清除那些没有标记的对象并且回收空间。

由于CMS并发清理阶段用户线程还在运行着，伴随程序运行自然就还会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS无法在当次收集中处理掉它们，只好留待下一次GC时再清理掉。这一部分垃圾就称为“浮动垃圾”。

并发重置

这个阶段并发执行，重新设置CMS算法内部的数据结构，准备下一个CMS生命周期的使用。

2、CMS需要注意的问题

1、CMS不是full GC

有一点需要注意的是：CMS并发GC不是“full GC”。HotSpot VM里对concurrent collection和full collection有明确的区分。所有带有“FullCollection”字样的VM参数都是跟真正的full GC相关，而跟CMS并发GC无关的，CMS收集算法只是清理老年代。

2、减少remark阶段停顿

一般CMS的GC耗时80%都在remark阶段，如果发现remark阶段停顿时间很长，可以尝试添加该参数：-XX:+CMSScavengeBeforeRemark。

在执行remark操作之前先做一次ygc(年轻代垃圾收集)，目的在于减少年轻代对老年代对象的无效引用，降低remark时的开销，如果添加该参数后 ”ygc停顿时间+remark时间<添加该参数之前的remark时间“,说明该参数是有效的。

3、内存碎片

CMS是基于标记-清除算法的，只会将标记为不存活的对象删除，并不会移动对象整理内存空间，会造成内存碎片，此时需要用到这个参数：-XX:CMSFullGCsBeforeCompaction=n。

CMS GC要决定是否在full GC时做压缩，会依赖几个条件。其中，

1. UseCMSCompactAtFullCollection 与 CMSFullGCsBeforeCompaction 是搭配使用的；前者目前默认就是true了，也就是关键在后者上。

2. 用户调用了System.gc()，而且DisableExplicitGC没有开启。

3. young gen报告接下来如果做增量收集会失败；简单来说也就是young gen预计old gen没有足够空间来容纳下次young GC晋升的对象。

上述三种条件的任意一种成立都会让CMS决定这次做full GC时要做压缩。

CMSFullGCsBeforeCompaction 说的是，在上一次CMS并发GC执行过后，到底还要再执行多少次full GC才会做压缩。默认是0，也就是在默认配置下每次CMS GC顶不住了而要转入full GC的时候都会做压缩。 如果把CMSFullGCsBeforeCompaction配置为10，就会让上面说的第一个条件变成每隔10次真正的full GC才做一次压缩（而不是每10次CMS并发GC就做一次压缩，目前VM里没有这样的参数）。这会使full GC更少做压缩，也就更容易使CMS的old gen受碎片化问题的困扰。本来这个参数就是用来配置降低full GC压缩的频率，以期减少某些full GC的暂停时间。CMS回退到full GC时用的算法是mark-sweep-compact，但compaction是可选的，不做的话碎片化会严重些，但这次full GC的暂停时间会短些，这是个取舍。

4、concurrent mode failure

这个异常发生在CMS正在回收的时候。执行CMS GC的过程中，同时业务线程也在运行，当年轻代空间满了，执行ygc时，需要将存活的对象放入到老年代，而此时老年代空间不足，这时CMS还没有机会回收老年带产生的，或者在做Minor GC的时候，新生代survivor区空间放不下，需要放入老年代，而老年代也放不下而产生的。

设置CMS触发时机有两个参数：

-XX:+UseCMSInitiatingOccupancyOnly

-XX:CMSInitiatingOccupancyFraction=70

-XX:CMSInitiatingOccupancyFraction=70是指设定CMS在对内存占用率达到70%的时候开始GC。如果不指定-XX:+UseCMSInitiatingOccupancyOnly，只是用设定的回收阈值CMSInitiatingOccupancyFraction，则JVM仅在第一次使用设定值，后续则自动调整会导致上面的那个参数不起作用。

为什么要有这两个参数？

由于在垃圾收集阶段用户线程还需要运行，那也就还需要预留有足够的内存空间给用户线程使用，因此CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，需要预留一部分空间提供并发收集时的程序运作使用。

CMS前五个阶段都是标记存活对象的，除了“初始标记”和“重新标记”阶段会stop the word ，其它三个阶段都是与用户线程一起运行的，就会出现这样的情况：gc线程正在标记存活对象，用户线程同时从年轻代向老年代提升新的对象，清理工作还没有开始，old gen已经没有空间容纳更多对象了，这时候就会导致concurrent mode failure， 然后就会使用串行收集器回收老年代的垃圾，导致停顿的时间非常长。

CMSInitiatingOccupancyFraction参数要设置一个合理的值，设置大了，会增加concurrent mode failure发生的频率，设置的小了，又会增加CMS频率，所以要根据应用的运行情况来选取一个合理的值。如果发现这两个参数设置大了会导致full gc，设置小了会导致频繁的CMS gc，说明老年代空间过小，应该增加老年代空间的大小了。

5、promotion failed

这个异常发生在年轻代回收的时候。

在进行Minor GC时，Survivor Space放不下，对象只能放入老年代，而此时老年代也放不下造成的，多数是由于老年带有足够的空闲空间，但是由于碎片较多，新生代要转移到老年带的对象比较大,找不到一段连续区域存放这个对象导致的，以下是一段promotion failed的日志：

106.641: [GC 106.641: [ParNew (promotion failed): 14784K->14784K(14784K), 0.0370328 secs]106.678: [CMS106.715: [CMS-concurrent-mark: 0.065/0.103 secs] [Times: user=0.17 sys=0.00, real=0.11 secs]

(concurrent mode failure): 41568K->27787K(49152K), 0.2128504 secs] 52402K->27787K(63936K), [CMS Perm : 2086K->2086K(12288K)], 0.2499776 secs] [Times: user=0.28 sys=0.00, real=0.25 secs]

过早提升与提升失败：（提升是指将年轻代中的对象复制到老年代中）

在Minor GC过程中，Survivor Unused可能不足以容纳Eden和另一个Survivor中的存活对象， 那么多余的年轻代中的对象将被移到老年代中，称为过早提升（Premature Promotion），这会导致老年代中短期存活对象的增多，可能会引发严重的性能问题。再进一步，如果老年代满了，Minor GC后会进行Full GC，这将导致遍历整个堆，称为提升失败（Promotion Failure）。

过早提升的原因：

1. Survivor空间太小，容纳不下全部的运行时短生命周期的对象，如果是这个原因，可以尝试将Survivor调大，否则短生命周期的对象提升过快，导致老年代很快就被占满，从而引起频繁的full gc；

2. 对象太大，Survivor和Eden没有足够大的空间来存放这些大对象。

提升失败的原因：

当提升的时候，发现老年代也没有足够的连续空间来容纳该对象。

为什么是没有足够的连续空间而不是空闲空间呢？

老年代容纳不下提升的对象有两种情况：

1. 老年代空闲空间不够用了；

2. 老年代虽然空闲空间很多，但是碎片太多，没有连续的空闲空间存放该对象。

解决方法

1. 如果是因为内存碎片导致的大对象提升失败，CMS需要进行空间整理压缩；

2. 如果是因为提升过快导致的，说明Survivor空闲空间不足，那么可以尝试调大Survivor；

3. 如果是因为老年代空间不够导致的，尝试将CMS触发的阈值调低。