如果说收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。java虚拟机规范中对垃圾收集器应该如何实现没有任何规定，因此产生了需要不同的垃圾收集器。一般都是根据自己的应用场景组合出各个年代所使用的收集器。
Serial收集器：
这是一个单线程收集器，它在进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束。但它依然是虚拟机运行在Client模式下的默认新生代收集器，它简单而高效（与其它收集器的单线程比）。
ParNew收集器：
ParNew收集器其实就是Serial收集器的多线程版本。它是许多运行在Server模式下的虚拟机中首选的新生代收集器。除了Serial收集器外，目前只有它能与CMS收集器配合工作。
这里解释一下并行和并发的概念：
并发是两个队列交替使用一台咖啡机，并行是两个队列同时使用两台咖啡机
并行：指多条垃圾收集线程并行工作，但此时用户线程仍处于等待状态。
并发：指用户线程与垃圾收集线程同时执行（但不一定是并行的，可能会交替执行），用户程序在继续运行，而垃圾收集程序运行在另一个CPU上。
Parallel Scavenge收集器：
这个收集器也经常被称为“吞吐量优先”收集器。它是新生代收集器也是使用复制算法，又是并行的多线程收集器，和ParNew都一样。Parallel Scavenge收集器的特点是它的目标是达到一个可控制的吞吐量。所谓的吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间）。
Serial Old收集器：
Serial Old是Serial收集器的老年代版本，它同样是一个单线程收集器，使用“标记-整理”算法。
Parallel Old收集器：
Parallel Old是Parallel Scavenge收集器的老年代版本，使用多线程和“标记-整理”算法。是注重吞吐量的老年代收集器。
CMS收集器：
CMS收集器是一种以获取最短回收停顿时间为目标的收集器，目前很大一部分的java应用集中在互联网站或者B/S系统的服务端上，这类重视服务响应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMS收集器非常符合这类应用的需求。
CMS收集器是基于“标记-清除”算法实现的。它的优点是并发收集、低停顿。也就是说，CMS收集器的内存回收过程是与用户线程一起并发执行的。
它的缺点是：1.CMS收集器对CPU资源非常敏感。（会占用一部分线程数或者说CPU资源而导致应用程序变慢）。2.CMS收集器无法处理浮动垃圾（垃圾出现在标记之后，只能下次处理）。3.收集结束后会产生大量空间碎片。
G1收集器：
G1是一款面向服务端应用的垃圾收集器。它的特点是：并行与并发、分代收集、空间整合、可预测的停顿。