CMS收集器与G1收集器

说明：本文摘自《深入理解Java虚拟机》，是自己看书总结文章。以下正文开始

收集器中的***并行（Parallel）***语义：指多条垃圾收集线程并行工作，但此时用户线程仍处于等待状态

收集器中的***并发（Concurrent）***语义：指用户线程与垃圾收集线程同时执行（但不一定是并行的，可能会交替执行），用户程序在继续运行，而垃圾收集程序于另一个CPU上。

###CMS收集器：
CMS（ConCurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器，从Mark-Sweep上可以看出，CMS收集器（以下简称CMS）是基于“标记-清除”算法实现的。主要应用于B/S模式的服务端（希望系统停顿时间尽可能短，尤其重视响应时间）
CMS的运作过程可以分为4个步骤

**1. 初始标记(CMS initial mark) **

**2. 并发标记(CMS concurrent mark) **

3. 重新标记(CMS remark)

4. 并发清除(CMS concurrent sweep)

1. 详细说明：初始标记（CMS initial Mark）是需要“Stop The World”。初始标记仅仅只是标记一下GC Roots能关联到的对象，速度很快。

2. 并发标记阶段就是进行GC Roots Tracing 的过程。

3. 重新标记阶段：因为并发标记阶段用户程序继续执行，导致原先标记产生变动，所以需要对原先标记的记录进行修正。从这个作用可以看出，重新标记阶段和初始标记阶段同样需要“Stop The World”。这个阶段的停顿时间一般比初始标记阶段稍长一点，但远比并发标记的时间要短。

4. 并发清除阶段：从前面的语义解释就可以看出，该阶段用户线程同垃圾清除线程同时执行（这里可以看出由于清除阶段用户线程还在运行， 自然就会产生新的垃圾（称为“浮动垃圾”）， 因为新产生的垃圾在垃圾标记阶段之后，所以这部分新产生的垃圾CMS无法在本次收集过程中处理掉它们，只能留到下次GC时再清理）。
   
   ####CMS收集器的缺点：

   1. 对CPU资源很敏感：CMS默认启动的回收线程数量是（CPU的个数+3）/4,如果CPU的个数在4个以上，
      收集器会占用不少于25%的CPU资源，CPU个数越多，收集器会占用不少于25%的CPU资源，
      CPU个数越多，CPU资源占比越小。但是当CPU不足4（例如2个）的时候，CMS收集器占用一半的运算能力去执行收集器线程。本来CPU负载就比较大，就会导致用户程序的执行效率下降的很明显。

   2. 无法处理浮动垃圾：由于最后的垃圾清除阶段是并发进行的，伴随着程序的运行产生的新的垃圾，在本次收集过程中无法处理掉，指的下次GC时再清理。
      而且还需要留足够的内存空间给用户线程使用，不能像其他收集器那样等到老年代几乎被填满了再进行收集，需要预留一部分空间提供并发收集时用户线程使用。

   3. 产生大量的空间碎片。CMS是基于“标记-清除”算法实现的收集器。因为这种算法在收集结束后有大量的空间碎片，当碎片过多时，会给大对象的内存
      分配带来很大麻烦，往往在老年代中还有很大空间剩余，但是无法找到足够大的连续空间来分配当前对象导致不得不提前触发一次Full GC。

###G1（Garbage First）收集器：
面向服务端应用的垃圾收集器。G1名称由来：G1收集器，Java堆的内存布局是将整个Java堆分为多个大小相等的独立区域（Region），也保留了新生代
和老年代的概念。但是新生代和老年代不再是物理隔离的，它们都是一部分Region的集合。G1跟踪各个Region里面的垃圾堆积的价值大小（也就是回收获得的空间大小以及回收需要的时间的经验值），在后台维护一个优先列表，每次根据允许的的收集时间，优先回收价值最大的Region。

G1的运作过程大致划分为几个步骤

1. 初始标记（Initial Marking）

2. 并发标记（Concurrent Marking）

3. 最终标记（Final Marking）

4. 筛选回收（Live Data Counting and Evacuation）

1. 详细说明第一步：初始标记（Initial Marking）,同CMS收集器很相似，仅仅是标记一下GC Root能关联到的对象，这阶段需要停顿线程，但耗时很短。

2. 并发标记（Concurrent Marking）：是从GC Root开始对堆中对象进行可达性分析，找出存活的对象，这阶段耗时比较长，但是可与用户程序并发执行。

3. 最终标记（Final Marking）：为了修正在并发标记期间因为用户程序执行而导致标记产生变动的那一部分的标记记录。所以这个阶段同初始标记阶段一样需要"Stop The World"。可以并行执行（即最终标记线程同时执行）。

4. 筛选回收（Live Data Counting Evacuation）：首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划。这个阶段也是"Stop The World"的。（这个阶段也可以做到同用户线程一起并发执行，因为只回收一部分Region时间是用户可控制的，停顿用户线程可以大幅提高收集效率。所以选择了“Stop The World”）。
   
   ####G1收集器的特点：

   1. 并行与并发：G1能充分利用多CPU,多核的硬件优势来缩短Stop—The—World停顿的时间，部分其它收集器原本需要停顿用户线程执行的GC动作，
      G1依然可以通过并发的方式让用户线程继续执行。

   2. 分代收集：同其它收集器一样，分代概念依然在G1中保留。G1可以不需要其它收集器配合就能独立管理整个GC堆，而且采用了不同的方式处理
      新创建的对象，已经存活一段时间的对象，熬过多次GC的旧对象，来获得更好的收集结果。

   3. 空间整合：使用算法从整体上来看是基于标记——整理实现的。局部来看，是基于“复制”算法实现的。所以G1在运作期间不会产生内存空间碎片，
      收集后能提供规整的可用内存。这有利于程序长时间运行。

   4. 可预测的停顿：G1同CMS都追求低停顿时间。但是G1还能建立可预测的停顿时间模型（通过有计划的避免在整个Java堆中进行全区域的垃圾收集，
      而是将整个Java堆分为多个大小相等的独立区域（Region），也保留了新生代和老年代的概念。但是新生代和老年代不再是物理隔离的，它们都是
      优先列表，每次根据允许的的收集时间，优先回收价值最大的Region。），能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集
      的时间上不超过N毫秒，这几乎是实时Java的垃圾收集器的特征。