JVMGC——并发收集器（CMS）

 CMS（Concurrent Mark Sweep）收集器

C :  Concurrent

M :  标记（marking）对象 ：GC必须记住哪些对象可达，以便删除不可达的对象 

S :  清除（sweeping） ： 删除未标记的对象并释放它们的内存

CMS是一种以最短停顿时间为目标的收集器，使用CMS并不能达到GC效率最高，但它尽可能降低GC时服务的停顿时间。

使用标记-清除算法（Mark Sweep），在运行时会产生内存碎片

虚拟机提供了参数开启CMS收集结束后再进行一次内存压缩。

-XX:+UseConcMarkSweepGC

激活CMS收集器。默认HotSpot JVM使用的是并行收集器

-XX:+UseCMSCompactAtFullCollection

设置在垃圾收集器后是否需要一次内存碎片整理过程，仅在CMS收集器时有效

-XX:+CMSFullGCBeforeCompaction

设置CMS收集器在进行若干次垃圾收集后再进行一次内存碎片整理过程

通常与UseCMSCompactAtFullCollection参数一起使用

CMS垃圾回收整个过程分为六个步骤：

1. 初始标记 (CMS initial mark)  会STW(Stop The World)

为了收集应用程序的对象引用需要暂停应用程序线程

该阶段完成后，应用程序线程再次启动

2. 并发标记 (CMS concurrent mark)

从第一阶段收集到的对象引用开始，遍历所有其他的对象引用

3. 并发预清理(CMS-concurrent-preclean)

改变当运行第二阶段时，由应用程序线程产生的对象引用，以更新第二阶段的结果

4. 重新标记 (CMS remark)  会STW

由于第三阶段是并发的，对象引用可能会发生进一步改变，因此应用程序线程会再一次被暂停以更新这些变化

并且在进行实际的清理之前确保一个正确的对象引用视图

5. 并发清理 (CMS concurrent sweep)  

所有不再被引用的对象将从堆里清除掉

6. 并发重置：

收集器做一些收尾的工作，以便下一次GC周期能有一个干净的状态

CMS的两个挑战：

1. 堆碎片

CMS收集器默认并没有任何碎片整理的机制。所以可能会出现这样的情形：

即使总的堆大小远没有耗尽但却不能分配对象，仅仅是因为没有足够连续的空间完全容纳对象。

当这种事发生后，JVM会触发Full GC

 

2. 对象分配率高

获取对象实例的频率高于收集器清除堆里死对象的频率

并发模式失败： 老年代没有足够的可用空间来容纳一个从年轻代提升过来的对象

此时JVM会执行堆碎片整理：触发Full GC

 

当这些情形之一出现的时候，经常被证实是老年代有大量不必要的对象。

一个可行的办法： 增加年轻代的堆大小（增加Survior区的个数），以防止年轻代生命周期短的对象提前进入老年代。

其他方法： 利用jmap和jhat分析过度的对象分配，找出这些对象，最终减少这些对象的申请。