CMS
CMS（Concurrent Mark Sweep） 收集器是一种以获取最短回收停顿时间为目标的收集器。 目前很大一部分的Java应用集中在互联网网站或者基于浏览器的B/S系统的服务端上， 这类应用通常都会较为关注服务的响应速度， 希望系统停顿时间尽可能短， 以给用户带来良好的交互体验。 CMS收集器就非常符合这类应用的需求。从名字（包含“Mark Sweep”） 上就可以看出CMS收集器是基于标记-清除算法实现的， 它的运作过程相对于前面几种收集器来说要更复杂一些， 整个过程分为四个步骤， 包括：
1） 初始标记（CMS initial mark）
2） 并发标记（CMS concurrent mark）
3） 重新标记（CMS remark）
4） 并发清除（CMS concurrent sweep）
其中初始标记、 重新标记这两个步骤仍然需要“Stop The World”。
- 优点
由于在整个过程中耗时最长的并发标记和并发清除阶段中， 垃圾收集器线程都可以与用户线程一起工作， 所以从总体上来说， CMS收集器的内存回收过程是与用户线程一起并发执行的。 所以停顿低，响应快。 - 缺点
1.CMS收集器对处理器资源非常敏感。
2.CMS收集器无法处理“浮动垃圾”
3.CMS是一款基于“标记-清除”算法实现的收集器， 所以可能会产生大量空间碎片。
G1
Garbage First（简称G1） 它开创了收集器面向局部收集的设计思路和基于Region的内存布局形式。 G1是一款主要面向服务端应用的垃圾收集器。
设计者们希望做出一款能够建立起“停顿时间模型”（Pause Prediction Model） 的收集器， 停顿时间模型的意思是能够支持指定在一个长度为M毫秒的时间片段内， 消耗在垃圾收集上的时间大概率不超过N毫秒这样的目标。
在G1收集器出现之前的所有其他收集器， 包括CMS在内， 垃圾收集的目标范围要么是整个新生代（Minor GC） ， 要么就是整个老年代（Major GC） ， 再要么就是整个Java堆（Full GC） 。 而G1跳出了这个笼子， 它可以面向堆内存任何部分来组成回收集（Collection Set， 一般简称CSet） 进行回收， 衡量标准不再是它属于哪个分代， 而是哪块内存中存放的垃圾数量最多， 回收收益最大， 这就是G1收集器的Mixed GC模式，G1不再坚持固定大小以及固定数量的分代区域划分， 而是把连续的Java堆划分为多个大小相等的独立区域（Region） ， 每一个Region都可以根据需要， 扮演新生代的Eden空间、Survivor空间， 或者老年代空间。 收集器能够对扮演不同角色的Region采用不同的策略去处理。
Region中还有一类特殊的Humongous区域， 专门用来存储大对象。G1认为只要大小超过了一个Region容量一半的对象即可判定为大对象。
在并发标记阶段如何保证收集线程与用户线程互不干扰地运行？ CMS收集器采用增量
更新算法实现， 而G1收集器则是通过原始快照（SATB） 算法来实现的。
G1收集器的运作过程大致可划分为以下四个步骤：
1.初始标记
2.并发标记
3.最终标记
4.筛选回收
-
优点
1.采用标记整理算法回收，无空间碎片 -
缺点
1.因垃圾收集产生的内存占用和额外运行负载高