CMS收集器

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。
CMS收集器是基于“标记-清除”算法实现的，它的运作过程相对于前面几种收集器来说更复杂，可以分为四个步骤：

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

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

  
  
  CMS
  
  

  CMS的优点是并发收集，低停顿，但是有三个明显的缺点：

• CMS收集器对CPU资源非常敏感。面向并发设计的程序都对CPU敏感。在并发阶段虽然不会导致用户线程停止，但是会因为占用一部分线程（或者说CPU资源）而导致应用程序变慢，总吞吐量会降低。
• CMS 收集器无法处理浮动垃圾（Floating Garbage），可能出现（Concurrent Mode Failure）失败而导致另一次Full GC的产生。因为CMS并发清理阶段用户线程还在运行着，伴随着程序运行自然就会产生新的垃圾，这一部分垃圾出现在标记过程之后，CMS无法当次收集这些垃圾。这一部分垃圾就称为浮动垃圾。
• 还有最后一个缺点是CMS 是基于“标记-清除”算法实现的收集器，这种收集算法会在垃圾手机结束时产生大量的碎片。空间碎片过多时，将会给大对象的分配带来很大的麻烦，往往会出现老生代还有很大的空间剩余，但是无法找到足够大的连续空间来分配当前对象，不得不提前触发一次Full GC

G1 收集器

G1（Garbage-Frist）收集器是当今收集器技术发展最前沿的成果之一，G1是一款面相服务端应用的垃圾收集器。HotSpot计划使用G1收集器替换掉JDK1.5中发布的CMS收集器， 与其他收集器相比G1具备以下几个特点：

• 并行和并发：G1能充分利用多CPU,多核环境下的硬件优势，使用多个CPU（CPU或者CPU核心）来缩短STW停顿时间，部分其他收集器原本需要停顿Java线程执行的GC动作，G1收集器仍然可以通过并发的方式让Java程序继续执行。
• 分代收集：与其他收集器一样，分代的概念在G1中依然存在。虽然G1可以不需要其他收集器配合就能管理整个GC堆，但它能够采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获取更好的收集效果。
• 空间整合：G1 从整体来看是基于“标记-整理”算法实现的收集器，从局部（两个region）上来看是基于“复制”算法实现的，这两种算法在收集期间都会导致内存碎片，不会应为大对象内存无法分配而导致Full GC
• 可预测的停顿： G1可以建立可预测的停顿时间模型，能让使用者明确指定一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒。
  G1收集器的运作步骤大致分为4步：
  • 初始标记（ Initial Marking）
  • 并发标记（ Concurrent Marking）
  • 最终标记（Final Marking）

  • 筛选回收（ Live Data Counting and Evacuation）
    前两步和CMS类似，最终标记是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录，虚拟机将这段事件对象的变化记录在线程Remembered Set Logs里面，最终标记阶段需要把Remembered Set Logs的数据合并到Remembered Set中，这阶段需要停顿线程，但是可并行执行。最后在筛选回收阶段首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划，这个阶段也可以做到和用户线程并发执行。

    
    
    G1