本文基于周志明的《深入理解java虚拟机 JVM高级特性与最佳实践》所写。特此推荐。
垃圾收集器是垃圾收集算法的具体实现，Java虚拟机对垃圾收集器如何实现并未做规定，因此不同厂商会有各自的垃圾收集器。如HotSpot虚拟机中的收集器如下所示，其中存在连线的收集器即可搭配使用。 但现在没有最好的收集器，都需要根据具体环境来选择。
Serial收集器
Serial收集器是最基本、发展历史最悠久的收集器。这个收集器是一个单线程的收集器，当它工作时必须暂停其他线程的工作，也就是Stop The World。这显示是它的缺点， 这也是垃圾收集器一直努力的方向。当然，对于相比其它单线程收集器，Serial收集器简单而高效。对于桌面应用来说，分配的管理内存不会太多，停顿时间完全可以控制在几十毫秒最多一百毫秒以内。所以，Serial收集器对于运行在Client模式下的虚拟机来说是一个很好的选择。下图为Serial结合Serial Old收集器（后续介绍）的运行过程：
ParNew收集器
ParNew收集器其实就是Serial收集器的多线程版本（多CPU下使用效果较好），下图为ParNew结合Serial Old收集器（后续介绍）的运行过程：
ParNew收集器对于Serial来说并没有太多的创新之处，但它却是许多运行在Server模式下的虚拟机中首选的新生代收集器，因为除了Serial收集器外，剩下只有它能与CMS收集器（后续介绍）配合工作了。所以，遗憾的是CMS作为老年代的收集器，却无法与JDK1.4中已经存在的新生代收集器Parallel Scavenge配合工作。
Parallel Scavenge收集器
Parallel Scavenge收集器是一个新生代收集器，它也是使用复制算法的收集器，又是并行的多线程收集器，看上去跟ParNew差不多。但是Parallel Scavenge收集器与其他收集器不同在于CMS等收集器的关注点在于尽可能地缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量（Throughput）。所谓的吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量 = 运行用户代码时间/（运行用户代码时间+垃圾收集时间），虚拟机总共运行了100分钟，其中垃圾收集花费1分钟，那吞吐量就是99%。
Parallel Scavenge收集器分别可通过-XX:MaxGCPauseMillis参数控制最大垃圾收集停顿时间以及直接设置吞吐量大小的-XX:GCTimeRatio参数。Parallel Scavenge收集器还有一个-XX:UseAdaptiveSizePolicy开关参数，打开参数后就不需要手动指定新生代的大小、Eden与Survivor区的比例、晋升老年代对象年龄等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整相关参数。这种调节方式叫自适应的调节策略，也是Parallel Scavenge收集器与ParNew收集器的一个重要区别。
Serial Old收集器
Serial Old是一个老年代收集器，它同样是一个单线程收集器，使用的是“标记-整理”算法。这个收集器的主要意义也是在于给Client模式下的虚拟机使用。如果在Server模式下，那么它主要还有两大用途：一种用途是在JDK1.5以及之前的版本中与Parallel Scavenge收集器搭配使用；另一种用途就是作为CMS收集器的后备方案，在并发收集发生ConCurrent Mode Failure时使用。
CMS收集器
CMS（Concurrent Mark Sweep）收集器是一种以获得最短回收停顿时间为目标的收集器。目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。从名字上就可以看出，CMS收集器是基于“标记-清除”算法实现的。但它的实际运作过程对于前面几种收集器来说更复杂一些，整个过程分为4个步骤：
- 初始标记（CMS initial mark）
- 并发标记（CMS concurrent mark）
- 重新标记（CMS remark）
- 并发清除（CMS concurrent sweep）
其中，初始标记、重新标记这两个步骤仍然需要“Stop The World”。初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快；并发标记阶段就是进行GC Roots Tracing的过程；而重新标记阶段则是为了修正并发标记期间用用户程序继续运作而导致标记产生的那一部分对象的标记记录。这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记时间短。由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，所以，从总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的（注意并发与并行的概念），如下图所示：
CMS是一款优秀的收集器，但是还远达不到的完美程度，它有以下3个明显缺点：
- CMS收集器对CPU资源非常敏感。因为在并发阶段，它会占用了一部分线程（或者说CPU资源）而导致应用程序变慢，总吞吐量会降低。
- CMS收集器无法处理浮动垃圾，可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。由于CMS并发清理阶段用户线程还在运行着，伴随着程序运行自然就还会有新的垃圾不断产生，这部分垃圾出现在标记过程之后，CMS无法在当次收集中处理它们，只好留待在下一次GC时再清理掉，这一部分垃圾就称为“浮动垃圾”。
- 还有最后一点，CMS是一款基于“标记-清除”算法实现的收集器，这意味着收集结束时会有大量的空间碎片产生。为了解决这个问题，CMS收集器提供了一个-XX:+UseCMSCompactAtFullColletion开关参数（默认是开启的），用于在CMS收集器顶不住要进行Full GC时开启内存碎片合并整理过程，内存整理的过程是无法并发的，空间的碎片问题没有了，但停顿的时间不得不变长了。虚拟机设计者还提供了另外一个参数-XX:CMSFullGCsBeforeCompaction，这个参数是用于设置执行多少次不压缩的Full GC后，跟着来一次带压缩的（默认值为0，表示每次进入Full GC时都进行碎片整理）。
G1收集器
G1（Garbage First）收集器是当今收集器技术发展的最前沿成果之一，从JDK 6u14中开始就有Early Acsess版本的G1收集器供开发人员实验、试用，由此开始G1收集器的 “Experimental” 状态持续了数年时间，直到JDK7u4，Sun公司才认为它达到足够成熟的商用程度，移除了“Experimental”的标识。G1是一款面向服务端应用的垃圾收集器。HotSpot开发团队赋予它的使命是未来可以替换掉JDK1.5中发布的CMS收集器。其与其它收集器相比，G1具备如下特点：
- 并行与并发：和CMS类似。
- 分代收集：分代概念在G1中依然得以保留。虽然G1可以不需要其它收集器配合就能独立管理整个GC堆，但它能够采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获取更好的收集效果。也就是说G1可以自己管理新生代和老年代了。
- 空间整合：由于G1使用了独立区域（Region）概念，G1从整体来看是基于“标记-整理”算法实现收集，从局部（两个Region）上来看是基于“复制”算法实现的，但无论如何，这两种算法都意味着G1运作期间不会产生内存空间碎片。
- 可预测的停顿：这是G1相对于CMS的另一大优势，降低停顿时间是G1和CMS共同的关注点，但G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用这明确指定一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒。
与其它收集器相比，G1变化较大的是它将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留了新生代和来年代的概念，但新生代和老年代不再是物理隔离的了它们都是一部分Region（不需要连续）的集合。同时，为了避免全堆扫描，G1使用了Remembered Set来管理相关的对象引用信息。当进行内存回收时，在GC根节点的枚举范围中加入Remembered Set即可保证不对全堆扫描也不会有遗漏了。
如果不计算维护Remembered Set的操作，G1收集器的运作大致可划分为以下几个步骤：
- 初始标记（Initial Making）
- 并发标记（Concurrent Marking）
- 最终标记（Final Marking）
- 筛选回收（Live Data Counting and Evacuation）
看上去跟CMS收集器的运作过程有几分相似，不过确实也这样。初始阶段仅仅只是标记一下GC Roots能直接关联到的对象，并且修改TAMS（Next Top Mark Start）的值，让下一阶段用户程序并发运行时，能在正确可以用的Region中创建新对象，这个阶段需要停顿线程，但耗时很短。并发标记阶段是从GC Roots开始对堆中对象进行可达性分析，找出存活对象，这一阶段耗时较长但能与用户线程并发运行。而最终标记阶段需要把Remembered Set Logs的数据合并到Remembered Set中，这阶段需要停顿线程，但可并行执行。最后筛选回收阶段首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划，这一过程同样是需要停顿线程的，但Sun公司透露这个阶段其实也可以做到并发，但考虑到停顿线程将大幅度提高收集效率，所以选择停顿。下图为G1收集器运行示意图：
