上图列举了七种作用于不同分代的垃圾收集器，如果两个收集器存在连线就说明可以搭配使用。收集器所处的区域表示它所属的年轻代还是老年代

属于年轻代的回收器

Serial收集器

简单高效且内存消耗小，适用于客户端模式下的虚拟机

该收集器是一个单线程工作的。意思是当它在进行垃圾回收时，必须暂停其他所有工作线程，直至它收集结束。Serial和Serial Old收集器的运行过程如图所示：

ParNew收集器

Serial收集器的的多线程版本，除了同时使用多个线程进行垃圾回收之外其余行为与Serial收集器一致。在JDK1.7之前是除了Serial收集器之外，只有它能与CMS收集器配合工作

Parallel Scavenge收集器

以吞吐量为指标的收集器，与ParNew收集器一样支持并行收集。使用两个参数用于精确控制吞吐量，也支持自适应调节策略-XX:MAXGCPauseMillis：控制最大垃圾回收停顿时间。允许设置一个大于0的数，收集器将尽力保证内存回收的时间不超过设定值

-XX:GCTimeRatio：配置吞吐量大小。参数的值是一个大于0小于100的整数。

属于老年代的收集器

Serial Old收集器

Serial收集器的老年代版本，是一个单线程收集器， 使用标记-压缩算法。在服务器端模式下，存在两种用途：在JDK5以及之前的版本中与Parallel Scavenge收集器搭配使用

作为CMS收集器发生失败之后的后备方案

Parellel Old收集器

Parellel Scavenge收集器的老年代版本，支持多线程并发收集，基于标记-压缩算法实现。

CMS收集器(Concurrent Mark Sweep)

是一种以获取最短回收停顿时间为目标的收集器，基于标记-清除算法实现。整个过程分为四个步骤：初始标记： 标记GC Roots能直接关联到的对象

并发标记：从GC Roots的直接关联对象开始遍历整个对象图

重新标记：修改并发标记期间因用户线程继续运作而导致标记产生变动的那部分对象

并发清除：清理删除标记阶段判定已经死亡的对象

缺点：由于使用标记-清除算法，在完成收集之后会产生碎片。碎片过多将会给大对象分配带来很大的麻烦，由于存在很多剩余的空间但是无法找到足够大的连续空间来分配对象，而不得不提前触发Full GC

G1收集器(Garbage First)

由于我使用的Java版本是1.8.0_231，默认年轻代收集器是Parallel Scavenge，老年代收集器是Parellel Old

G1收集器在Java9才是默认配置，要在Java8上使用G1可以添加-XX:+UseG1GC才可以实现

G1的运作过程：初始标记：标记GC Roots可以关联到的对象修改TAMS指针的值，让下一个阶段用户线程并发执行时能够正确的在可用的Ragion中分配对象

并发标记：从GC Roots开始对堆中的对象进行可达性分析，扫描堆中整个对象图

最终标记：对用户线程做一个短暂的暂停，用于处理并发阶段结束后仍然留下来的记录

筛选回收：更新Ragion的统计数据并根据用户期望的停顿时间来制定回收计划

有关G1的相关文章：