CMS 和 G1 收集器比较

CMS 垃圾收集器

　　

　　CMS(Concurrent Mark Sweep) 收集器是一种 以获取最短回收停顿时间为目标 的收集器。

　　目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，已给用户带来较好的体验。

　　从字面上可以看出CMS收集器是基于 “标记-清除” 算法实现的。整个过程分为4个步骤：

• 初始标记（CMS initial mark）
• 并发标记（CMS concurrent mark）
• 重新标记（CMS remark）
• 并发清除（CMS concurrent sweep）

　　其中初始标记、重新标记这两个步骤仍然需要 “Stop The World”。初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，并发标记阶段就是进行 GC Roots Tracing 过程，而重新标记阶段则是为了修正并发标记期间因用户程序继续运行而导致标记产生变动的那一部分，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短。

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

　　CMS 运行期间预留的内存无偿满足程序需要，就会出现一次"Concurrent Mode Failure"，一般这是由于参数 -XX:CMSInitiatingOccupancyFraction 设置得太高导致的。这时虚拟机将启动后备预案：临时启动 Serial Old 收集器来重新进行老年代的垃圾收集，这样停顿时间就会很长。在JDK1.5的默认设置下，CMS收集器当老年代使用了68%的空间后就会被激活进行垃圾收集。而在JDK1.6中，CMS启动阀值已经提升至92%。出于安全或者高性能方面出发，一般设置为：70%~80%之间是最好的，我的服务器设置的是75%。

　　收集结束时会产生大量空间碎片。CMS 基于“标记一清除”算法实现。多次垃圾收集后，空间碎片过多，给大对象分配带来很大的麻烦，往往会出现老年代还有很大的空间剩余，但是无法找到足够大的连续空间来分配当前对象，不得不提前触发一次Full GC，CMS收集器要进行FullGC时开启内存碎片整理。使用 -XX:+UseCMSCompactAtFullCollection 开关设置，默认是开启的命令表明GC后要进行空间碎片整理，虚拟机还提供了另外一个参数用于设置执行多少次不压缩的Full GC后再进行碎片整理：-XX:CMSFullGCsBeforeCompaction

　　默认值为0，表示每次进入FullGC 时都进行碎片整理。

 G1 垃圾收集器

　　

G1收集器的特点

　　G1是一款面向服务端应用的垃圾收集器，Oracle赋予它的使命是未来可以替换掉JDK 5中发布的CMS（Concurrent Mark Sweep）收集器，与其他GC收集器相比，G1具备如下特点：

• 并行与并发：G1能充分利用多CPU、多核环境下的硬件优势，使用多个CPU来缩短 Stop-The-World 停顿的时间，部分其他收集器原本需要停顿Java线程执行的GC动作，G1收集器仍然可以通过并发的方式让Java程序继续执行。
• 分代收集：与其他收集器一样，分代概念在G1中依然得以保留。虽然G1可以不需其他收集器配合就能独立管理整个GC堆，但它能够采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获取更好的收集效果。
• 空间整合：与CMS的 “标记-清理” 算法不同，G1从整体看来是基于 “标记-整理” 算法实现的收集器，从局部（两个Region之间）上看是基于“复制” 算法实现，无论如何，这两种算法都意味着G1运作期间不会产生内存空间碎片，收集后能提供规整的可用内存。这种特性有利于程序长时间运行，分配大对象时不会因为无法找到连续内存空间而提前触发下一次GC。
• 可预测的停顿：这是G1相对于CMS的另外一大优势，降低停顿时间是G1和CMS共同的关注点，但G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过 N毫秒，这几乎已经是实时Java（RTSJ）的垃圾收集器特征了。

实现思路

　　在G1之前的其他收集器进行收集的范围都是整个新生代或者老年代，而G1不再是这样。使用G1收集器时，Java堆的内存布局就与其他收集器有很大差别，它将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，它们都是一部分Region（不需要连续）的集合。

　　G1收集器之所以能建立可预测的停顿时间模型，是因为它可以有计划地避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个Region里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的 Region（这也就是Garbage-First名称的来由）。这种使用Region划分内存空间以及有优先级的区域回收方式，保证了G1收集器在有限的时间内获可以获取尽可能高的收集效率。

        在G1收集器中Region之间的对象引用以及其他收集器中的新生代与老年代之间的对象引用，虚拟机都是使用Remembered Set来避免全堆扫描的。G1中每个Region都有一个与之对应的Remembered Set，虚拟机发现程序在对Reference类型的数据进行写操作时，会产生一个Write Barrier（写屏障）暂时中断写操作，检查Reference引用的对象是否处于不同的Region之中（在分代的例子中就是检查引用是否老年代中的对象引用了新生代中的对象），如果是，便通过CardTable把相关引用信息记录到被引用对象所属的Region的Remembered Set之中。当进行内存回收时，GC根节点的枚举范围中加入Remembered Set即可保证不对全堆扫描也不会有遗漏。