- CMS收集器
CMS(Concurrent Map Sweep)收集器是一种以最短回收停顿时间为目标的收集器，通常用于JavaWeb程序上，重视服务响应速度，希望系统时间停顿最短，而它是基于"标记-清除"算法。
整个过程分为四个步骤：
-
-
- 初始标记
-
只是标记一下GC Roots能直接关联到的对象，速度很快。
-
-
- 并发标记
-
是进行GC RootsTracing的过程
-
-
- 重新标记
-
修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短。
-
-
- 并发清除
-
清除标记
由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，所以从总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的。
但是它也如下缺点：
-
-
- CMS收集器对CPU资源非常敏感。在并发阶段，它虽然不会导致用户线程停顿，但是会因为占用了一部分线程（或者说CPU资源）
- CMS收集器无法处理浮动垃圾。由于CMS并发清理阶段用户线程还在运行着，伴随程序运行自然就还会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS无法在当次收集中处理掉他们，只好留待下一次GC时再清理掉。
- CMS收集器是基于”标记-清除“算法实现的收集器。收集结束时会有大量空间碎片产生。空间碎片过多时，将会给大对象分配带来很大麻烦，往往会出现老年代还有很大空间剩余，但是无法找到足够大的连续空间来分配当前对象，不得不提前出发一次FullGC。
-
- G1收集器
-
- 并行与并发
-
G1能充分利用多CPU、多核环境下的硬件优势，使用多个CPU来缩短Stop-The-World停顿的时间，部分其他收集器原本需要停顿Java线程执行的GC动作，G1收集器仍然可以通过并发的方式让Java程序继续执行。
-
-
- 分代收集
-
分代手机的概念在G1中依然得以保留。
-
-
- 空间整合
-
G1从整体上来看是基于“标记-整理”算法实现的收集器，从局部（两个Region之间）上来看是基于“复制”算法实现的。可以保证G1运作期间不会产生内存空间碎片，收集后能提供规整的可用内存。
-
-
- 可预测的停顿
-
G1可以建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒。
G1将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留有新生代老年代的概念，但新生代和老年代不再是物理隔离的了，它们都是一部分Region（不需要连续）的集合。
G1收集器之所以能建立可预测的停顿时间模型，是因为它可以有计划的避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个Region里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需的时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region（这也就是Garbage-First名称的来由）。
G1收集器的运作大致可划分为以下几个步骤：
-
-
- 初始标记
-
仅仅是标记一下GC Roots能直接关联到的对象，并且修改TAMS（Next Top at Mark Start）的值，让下一阶段用户程序并发运行时，能在正确可用的Region中创建新对象，这阶段需要停顿线程，但耗时很短。
-
-
- 并发标记
-
从GC Root开始对堆中对象进行可达性分析，找出存活的对象，这阶段耗时较长，但可与用户程序并发执行。
-
-
- 最终标记
-
把Remembered Set Logs 的数据合并到Remembered Set 中，这阶段需要停顿线程，但是可并行执行。
-
-
- 筛选回收
-
首先对各个Region的回收价值和成本进行排序，根据用户期望的GC停顿时间来制定回收计划。