1、Serial收集器
Serial收集器时最基础、历史最悠久的收集器，JDK1.3.1之前是HotSpot虚拟机新生代收集器的唯一选择。这个收集器是一个单线程工作收集器，这里的“单线程”的意义并不仅仅是说明它只会使用一个处理器或者一条收集线程去完成垃圾收集工作，更重要的是强调在它进行垃圾收集时，必须暂停其他所有工作线程，直到它收集结束（Stop The World）。
Serial/Serial Old收集器运行过程示意图：
2、ParNew收集器
ParNew收集器实质上时Serial收集器的多线程并行版本，除了同时使用多条线程进行垃圾收集之外，其余的行为包括Serial收集器可用的所有控制参数（例如：-XX：SurvivorRatio、-XX：PretenureSizeThreshold、-XX：HandlePromotionFailure等）、收集算法、Stop The World、对象分配原则、回收策略都与Serial收集器完全一致。ParNew收集器的工作过程如图：
ParNew收集器除了支持多线程并行收集之外，其他与Serial收集器相比并没有太多的创新之处，但它却是不少运行在服务端模式下的HotSpot虚拟机，尤其是JDK7之前的遗留系统中首选的新生代收集器，其中有一个与功能、性能无关的但其实很重要的原因：除了Serial收集器外，目前只有它能与CMS收集器配合工作。
3、Parallel Scavenge收集器
Parallel Scavenge收集器也是一款新生代收集器，它同样是基于标记-复制算法实现的收集器，也是能够并行收集的多线程收集器。
Parallel Scavenge收集器的特点是它的关注点与其他收集器不同，CMS等收集器的关注点是尽可能地算短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量（Throughput）。所谓吞吐量就是处理器用于运行用户代码时间与处理器总消耗时间的比值。
Parallel Scavenge收集器提供了两个参数用于精确控制吞吐量，分别是控制最大垃圾收集停顿时间的 -XX：MaxGCPauseMillis参数以及直接设置吞吐量大小的-XX：GCTimeRatio参数。
4、Serial Old收集器
Serial Old时Serial收集器的老年代版本，它同样是一个单线程收集器，使用标记-整理算法。这个收集器的主要意义也是提供客户端模式下的HotSpot虚拟机使用。如果在服务端模式下，它也可能有两者用途：一种是在JDK5以及之前的版本中与Parallel Scavenge收集器搭配使用，另外一种是作为CMS收集器发生失败时的后背预案，在并发收集发生Concurrent Mode Failure时使用。
5、Parallel Old收集器
Parallel Old是Parallel Scavenge收集器的老年代版本，支持多线程并发收集，基于标记-整理算法实现。这个收集器直到JDK6时才开始提供，在此之前，新生代的Parallel Scavenge收集器一直处于相当尴尬的状态，原因是如果新生代选择了Parallel Scavenge收集器，老年代除了Seral Old收集器外别无选择，其他表现良好的老年代收集器，如CMS无法与它配合工作。直到Parallel Old收集器出现后，“吞吐量优先”的收集器终于有了名副其实的搭配组合，在注重吞吐量或者处理器资源稀缺的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器这个组合。Parallel Old收集器工作过程如图：
6、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 的直接关联对象开始遍历整个对象图的过程，这个过程耗时比较长但是不需要停顿用户线程 ，可以与垃圾收集线程一起并发运行；而重新标记阶段则是为了修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间通常会比初始标记阶段稍长一些，但也远比并发标记阶段的时间短；最后是并发清楚阶段，清理删除掉标记阶段判断的已经死亡的对象，由于不需要移动存活对象，所以这个阶段也是可以与用户线程同时并发的。
CMS收集器运行示意图：
CMS是一款优秀的收集器，它的主要优点在名字上已经体现出来了：并发收集、低停顿，一些官方公开文档里面称之为“并发低停顿收集器”（Concurrent Low Pause Collector）。CMS收集器是HotSpot虚拟机追求低停顿的第一次成功尝试，但是它还远远达不到完美的程度，至少有以下三个明显的缺点：
- CMS收集器对处理器资源非常敏感。事实上，面向并发设计的程序都对处理器资源比较敏感。在并发阶段，它虽然不会导致用户线程停顿，但却会因为占用了一部分线程（或者说处理器的计算能力）而导致应用程序变慢，降低总吞吐量。
- CMS收集器无法处理“浮动垃圾”（Floating Garbage），有可能出现“Concurrent Mode Failure”失败进而导致另一次完全“Stop The World” 的Full GC的产生。在CMS并发标记和并发清理阶段，用户线程还是在继续运行的，程序自然就会伴随有新的垃圾产生，但这一部分垃圾对象是出现在标记过程结束以后，CMS无法在当次收集中处理掉它们，只好留待下一次垃圾收集时再清理掉。这一部分垃圾称为“浮动垃圾”。
- CMS是一款基于“标记-清除”算法实现的收集器，收集结束时会有大量的空间碎片产生。空间碎片过多时会对大对象分配带来很大麻烦，往往会出现老年代还有很多剩余空间，但是无法找到足够大的连续空间来分配当前对象，不得不提前触发一次Full GC的情况。
参考书籍——《深入理解Java虚拟机》 周志明；