如果说收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。Java 虚拟机规范中对垃圾收集器应该如何实现并没有任何规定，因此不同的厂商、不同的版本的虚拟机所提供的垃圾收集器都可能会有很大差别，并且一般都会提供参数供用户根据自己的应用特点和要求组合出各个年代所使用的收集器。
上图展示了7中不同分代的收集器，如果两个收集器之间存在连线，就说明他们可以搭配使用。虚拟机所在的区域，则表示它是属于新生代收集器还是老年代收集器。
Serial 收集器
Serial收集器是最基本、发展历史最悠久的收集器。这个收集器是一个单线程的收集器，但它的“单线程”的意义并不仅仅说明它只会使用一个CPU或一条收集线程去完成垃圾收集工作，更重要的是在它进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束。“Stop the world”这个名字也许听起来很酷，但这项工作实际上是有虚拟机在后台自动发起和自动完成的，在用户不可见的情况下把用户正常工作的线程全部停掉，这是一种很不友好的体验。
虽然看起来Serial收集器像一个“老而无用，食之无味弃之可惜”的鸡肋，但实际上到现在为止，它依然是虚拟机运行在Client模式下的默认新生代收集器，它也有着由于其他收集器的地方：简单而高效，对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率。
所以，Serial模式收集器对于Cline模式下的虚拟机来说是一个很好的选择。
PerNew 收集器
Pernew 收集器其实就是Serial收集器的多线程版本，除了使用多线程进行垃圾收集外，其余的行为包括Serial收集器可用的所有控制参数、收集算法、Stop The World、对象分配规则、回收策略等都与Serial收集器完全一样。
Pernew 是许多运行在Server模式下的虚拟机中首选的新生代收集器、其中有一个与性能无关但很重要的是，除了Serial收集器外。目前只有它能与CMS收集器配合工作。
从PerNew收集器开始，后面还会接触到几款并发和并行的收集器。有必要解释两个名词：并发和并行。
并行（Parallel）：指多条垃圾收集线程并行工作，但此时用户仍然处于等待状态。
并发（Concurrent）：指用户线程与垃圾收集线程同时执行，用户程序在继续运行，而垃圾收集程序运行与另外一个CPU上。
Parallel Scavenge收集器
Parallel Scavenge收集器是一个新生代收集器，它也是使用复制算法的收集器，又是并行的多线程收集器。它的特点是它的关注点与其他收集器不同，CMS等收集器的关注点是尽可能缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量。所谓吞吐量就是CPU 用于运行用户代码的时间与CPU总消耗时间的壁纸，即：
吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间），虚拟机总共运行了100分钟，其中垃圾收集花掉了1分钟，那吞吐量就是99%
停顿时间越短就越适合需要与用户交互的程序，良好的响应速度能提升用户体验，而高吞吐量则可以高效率地利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。
Serial Old 收集器
Serial Old 是Serial 收集器的老年代版本，它同样是一个单线程收集器，使用“标记-整理”算法。这个收集器的主要意义也是在于给Client 模式下的虚拟机使用，如果在server模式下，那么它主要还有两大用途：一种用途是JDK1.5以及之前的版本中与Parallel Scavenge收集器搭配使用。另一种用途就是作为CMS收集器的后备员，在并发收集发生Concurrent Mode Failure 时使用。
Perallel Old 收集器
Parallel Old是Parallel Scavenge收集器的老年代版本，使用多线程和“标记-整理”算法。这个收集器是在JDK1.6中才开始提供的，在此之前，新生代的Parallel Scavenge收集器一直处于比较尴尬的状态。原因是，如果新生代选择了Parallel Scavenge收集器，老年代除了Serial Old收集器外别无选择。由于老年代Serial Old 收集器在服务端应用性能上的“拖累”，使用了Parallel Scavenge收集器也未必能在整体应用上获得吞吐量最大化的效果，由于单线程的老年代收集中无法充分利用服务器多CPU的处理能力，在老年代很大而且硬件比较高级的环境中，这种组合的吞吐量甚至还不一定有ParNew加CMS的组合给力。
直到Parallel Old收集器出现后，“吞吐量优先”收集器终于有了比较名副其实的应用组合，在注重吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge加Parallel Old。
CMS 收集器
CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。目前大部分的Java应用几种在互联网或者B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMS收集器就非常符合这类应用的需求。
CMS 收集器是基于“标记-清除”算法实现的，它的运作过程相对于前面几种收集器来说更复杂一些，整个过程分为4个步骤：
1、初始标记
2、并发标记
3、重新标记
4、并发清除
其中、初始标记和重新标记着两个步骤仍然需要“Stop The World”。初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，并发标记阶段就是进行GC Roots Tracing的过程，而重新标记阶段则是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长，但远比并发标记时间短。
由于这个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，所以，从总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的。
CMS的3个明显缺点：
1、CMS收集器对CPU资源非常敏感。其实面向并发设计的程序都对CPU资源比较敏感。在并发阶段，它虽然不会导致用户线程停顿，但是会因为占用了一部分线程而导致应用程序变慢，总吞吐量会降低。为了解决这个问题，虚拟机提供了一种“增量式并发收集器”，但效果不好，并不推荐使用
2、CMS收集器无法处理浮动垃圾，可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。由于CMS并发清理阶段用户线程还在运行着，伴随程序运行自然就还会有新的垃圾产生，这一部分垃圾出现在标记过程之后，CMS就不发在当次收集中处理他们，只能下一次GC的时候再清理。
3、最后一个缺点是CMS采用的是“标记-清除”算法，这样就会导致GC之后会产生大量的空间碎片，为了解决这个问题，就可以通过设置-XX:+UserCMSCompactAtFullCollection开关参数，用于在CMS收集器顶不住要进行FullGC时开心内存碎片的合并整理过程，内存整理的过程是无法并发的，但这样停顿的时间不得不边长。然后又提供了一个参数—XX:CMSFullGCsBeforeCompaction：这个参数用于设置执行多少次不压缩的Full GC之后，跟着来一次代压缩的。
G1 收集器
G1 收集器是一款面向服务端应用的垃圾收集器。G1具备以下特点：
并行与并发：G1能充分利用多CPU、多核环境下的硬件优势，使用多个CPU来缩短 Stop the Wrold停顿时间，部分其他收集器原本需要停顿Java线程执行GC动作，G1收集器仍然可以通过并发的方式让Java 程序继续执行
分代收集：与其他收集器一样，分代概念在G1中依然得以保留，虽然G1可以不要其他收集器搭配就能独立管理整个GC堆，但它能够采用不同的方式去处理新创建的对象和已经存活一段时间、熬过多次GC的旧对象以获取更好的收集效果。
空间整合：与CMS的“标记-清理”算法不同，G1从整体来看是基于“标记-整理”算法实现的收集器，从局部上来看是基于“复制”算法实现的，但无论如何，这两种算法都意味着G1运作期间不会产生内存空间碎片，收集后能提供规整的可用内存。
可预测的停顿：这是G1相对于CMS的另一大优势，降低停顿时间是G2和CMS的关注点，但G1除了最求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒。
使用G2收集器时，Java堆的内存布局就与其他的收集器有很大差别，它将真个Java堆划分为多个大小相等的独立区域，虽然还保留着新生代和老年代的区别，他们都是一部分Region的集合。
G1收集器的运作大致可分为
初始标记
并发标记
最终标记：为了修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分记录。
筛选回收：对各个Region的回收价值和成本进行排序，根据用户期望GC停顿使劲一起并发执行。
缺点：还不成熟，需要更多的测试数据