如果说垃圾回收算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现，java虚拟机实现规范中对垃圾收集器应该如何实现并没有任何规定，因此不同厂商、不同版本的虚拟机提供的垃圾收集器存在很大的差异，接下来我们主要介绍一下HOTSPOT虚拟机中的几种垃圾收集器。这个虚拟包含的收集器如下图：

上图中7中作用于不同分代的收集器，如果两个之间存在连线，就说明他们可以搭配使用。收集器所处于的区域，则代表它是属于新生代收集器还是老年代收集器。

并发垃圾收集和并行垃圾收集 

在介绍垃圾收集器前，我们首先认识两个概念，并行垃圾收集和并发垃圾收集

（A）、并行（Parallel）

指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态；

如ParNew、Parallel Scavenge、Parallel Old；

（B）、并发（Concurrent）

指用户线程与垃圾收集线程同时执行（但不一定是并行的，可能会交替执行）；

用户程序在继续运行，而垃圾收集程序线程运行于另一个CPU上；    

如CMS、G1（也有并行）；

新代垃圾收集器

Serial 垃圾收集器（单线程）

大家看名字就知道这是一个 单线程的收集器，但它的“单线程”并不仅仅说明它只会使用一个CPU或者一条收集线程去完成垃圾回收工作，更重要的是它在进程垃圾回收的时候，必须暂停其他所有的工作线程（Stop The World），直到它收集结束。在用户不知情的情况下，暂停了用户所有的线程，这听起来实在是不可思议。那么这个线程是不是现在就被放弃使用了。 并不是这样，该收集现在仍然是运行在Client模式下的虚拟机的默认新生代垃圾收集器。该收集器的运行过程如下：

ParNew 垃圾收集器（多线程） 

ParNew收集器其实就是serial收集器的多线程的版本，除了使用多线程进行垃圾收集之外，其余的行为包括控制参数和收集算法，STW，对象分配规则，回收策略 等都与Serial收集器完全一样，在实现上两个收集器也共用了很多的代码。

虽然ParNew收集器和Serial收集器没有太多的创新之处，但是他却是 很多运行在Server 模型下的虚拟机中首先新生代 收集器，其中一个与性能没有关系的但是 很重要的一个原因是，目前除了Serial 收集器 外，目前只有它能与CMS收集器配合工作。

Parallel Scavenge 垃圾收集器（多线程）

Parallel Scavenge 收集器也是 新生代收集器，它也是采用的复制算法，又是并行的多线程收集器，看上去和ParNew收集器差不多，但是这两者有很大的差别。

1、Parallel Scavenge 收集器追求CPU吞吐量，能够在较短时间内完成垃圾收集任务，因此适合没有交互的后台计算，而ParNew：追求降低用户停顿时间，适合交互式应用。

吞吐量 = 运行用户代码时间 / (运行用户代码时间 + 垃圾收集时间)

追求高吞吐量，可以通过减少 GC 执行实际工作的时间，然而，仅仅偶尔运行 GC 意味着每当 GC 运行时将有许多工作要做，因为在此期间积累在堆中的对象数量很高。单个 GC 需要花更多的时间来完成，从而导致更高的暂停时间。而考虑到低暂停时间，最好频繁运行 GC 以便更快速完成，反过来又导致吞吐量下降。

• 通过参数 -XX:GCTimeRadio 设置垃圾回收时间占总 CPU 时间的百分比。
• 通过参数 -XX:MaxGCPauseMillis 设置垃圾处理过程最久停顿时间。
• 通过命令 -XX:+UseAdaptiveSizePolicy 开启自适应策略。我们只要设置好堆的大小和 MaxGCPauseMillis 或 GCTimeRadio，收集器会自动调整新生代的大小、Eden 和 Survivor 的比例、对象进入老年代的年龄，以最大程度上接近我们设置的 MaxGCPauseMillis 或 GCTimeRadio。

老年代垃圾收集器

Serial Old垃圾收集器（单线程）

Serial Old收集器是Serial收集器的老年代版本，同样是单线程收集器， 使用“标记-整理”算法。这个收集器的意义也是在client模式下使用。如果在Server模式下，那么它主要由两大 用途：一种是在JDK1.5之前版本中与Paralle Scavenge收集器搭配使用，另一种用途是作为CMS收集器的后备预案，在并发收集发生Concurrent model failure时使用。

 Parallel Old 垃圾收集器（多线程）

Parallel Old收集器是Parallel收集器的老年代版本， 使用多线程和“标记-清除算法”。这个收集器是在JDK1.6才开始提供的，再次之前新生代收集器 Parallel Scavenge收集器处于一个比较尴尬的地位，因为新生代选择了Parallel Scavenge收集器老年代只能选择Serial Old收集器。由于Serial Old在性能上的拖累，使用了Parallel Scavenge收集器也未必能在整体应用上获得吞吐量最大化的效果，由于单线程的老年代收集中无法充分利用服务器的多CPU的处理能力，在老年代很大并且硬件条件比较高级的环境，这种组合的吞吐量甚至不一定有ParNew+CMS的组合给力。

 CMS 垃圾收集器

CMS垃圾收集器是一种以 获取最短回收  停顿时间为目标的收集器。目前 很大一部分的java应集中在 互联网或者B/S系统服务端上。CMS收集器是基于“标记-清除”算法实现的，它的运作过程分为下面几个部分：

• 初始标记：Stop The World，仅使用一条初始标记线程对所有与 GC Roots 直接关联的对象进行标记。
• 并发标记：使用多条标记线程，与用户线程并发执行。此过程进行可达性分析，标记出所有废弃对象。速度很慢。
• 重新标记：Stop The World，使用多条标记线程并发执行，将刚才并发标记过程中新出现的废弃对象标记出来。
• 并发清除：只使用一条 GC 线程，与用户线程并发执行，清除刚才标记的对象。这个过程非常耗时。

CMS是一款优秀的收集器，它的主要优点已经体现出来了：并发收集，低停顿，Sun公司的一些官方文档也称之为并发低停顿收集器。当然，CMS收集器也并不是 一个十全十美的收集器，它的缺点主要包括 下面几个方面：

• 吞吐量低
• 无法处理浮动垃圾，导致频繁 Full GC
• 使用“标记-清除”算法产生碎片空间

对于产生碎片空间的问题，可以通过开启 -XX:+UseCMSCompactAtFullCollection，在每次 Full GC 完成后都会进行一次内存压缩整理，将零散在各处的对象整理到一块。设置参数 -XX:CMSFullGCsBeforeCompaction告诉 CMS，经过了 N 次 Full GC 之后再进行一次内存整理。

G1通用收集器

G1 是一款面向服务端应用的垃圾收集器，它没有新生代和老年代的概念，而是将堆划分为一块块独立的 Region。当要进行垃圾收集时，首先估计每个 Region 中垃圾的数量，每次都从垃圾回收价值最大的 Region 开始回收，因此可以获得最大的回收效率。

从整体上看， G1 是基于“标记-整理”算法实现的收集器，从局部（两个 Region 之间）上看是基于“复制”算法实现的，这意味着运行期间不会产生内存空间碎片。

这里抛个问题：
一个对象和它内部所引用的对象可能不在同一个 Region 中，那么当垃圾回收时，是否需要扫描整个堆内存才能完整地进行一次可达性分析？

并不！每个 Region 都有一个 Remembered Set，用于记录本区域中所有对象引用的对象所在的区域，进行可达性分析时，只要在 GC Roots 中再加上 Remembered Set 即可防止对整个堆内存进行遍历。

如果不计算维护 Remembered Set 的操作，G1 收集器的工作过程分为以下几个步骤：

• 初始标记：Stop The World，仅使用一条初始标记线程对所有与 GC Roots 直接关联的对象进行标记。
• 并发标记：使用一条标记线程与用户线程并发执行。此过程进行可达性分析，速度很慢。
• 最终标记：Stop The World，使用多条标记线程并发执行。
• 筛选回收：回收废弃对象，此时也要 Stop The World，并使用多条筛选回收线程并发执行。

小结

HotSpot 虚拟机提供了多种垃圾收集器，每种收集器都有各自的特点，虽然我们要对各个收集器进行比较，但并非为了挑选出一个最好的收集器。我们选择的只是对具体应用最合适的收集器。