垃圾收集器

如果说收集算法是内存回收的方法论，垃圾收集器就是内存回收的具体实现。 

Serial 收集器 

Serial 收集器是最基本、历史最悠久的收集器。

这个收集器是一个单线程收集器，但它的 “单线程” 的意义并不仅仅是说明它只会使用一个 CPU 或者一条收集线程去完成垃圾收集工作，更重要的是在它进行垃圾收集时，必须暂停其他所有的工作线程（Sun 将这件事情称之为 “Stop The World”），直到它收集结束。“Stop The World” 这个名字也许听起来很酷，但这项工作实际上是由虚拟机在后台自动发起和自动完成的，在用户不可见的情况下把用户的正常工作的线程全部停掉，这对很多应用来说都是难以接受的。Serial / Serial Old 收集器的运行过程如下图：

虽然 “Stop The World” 会带给用户恶劣的体验，但实际上到现在为止，它依然是虚拟机运行在 Client 模式下的默认新生代收集器。它也有着优于其他收集器的地方：简单而高效（与其他收集器的单线程比），对于限定单个 CPU 的环境来说，Serial 收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率。

在用户的桌面应用场景中，分配给虚拟机管理的内存一般来说不会很大，收集几十兆甚至一两百兆的新生代（仅仅是新生代使用的内存，桌面应用基本不会再大了），停顿时间完全可以控制在几十毫秒最多一百毫秒以内，只要不是频繁发生，这点停顿是可以接受的。

所以，Serial 收集器对于运行在 Client 模式下的虚拟机来说是一个很好的选择。

 

ParNew 收集器

ParNew 收集器其实就是 Serial 收集器的多线程版本，除了使用多条线程进行垃圾收集以外，其余行为包括 Serial 收集器可用的所有控制参数、收集算法、Stop The World、对象分配规则、回收策略等都与 Serial 收集器完全一样，实际上这两种收集器也共用了先当多的代码。ParNew / Serial Old 收集器的工作过程如下图：

ParNew 收集器除了多线程收集之外，其他与 Serial 收集器相比并没有太多的创新之处，但它却是许多运行在 Server 模式下的虚拟机中首选的新生代收集器，其中有一个与性能无关但很重要的原因是，除了 Serial 收集器外，目前只有它能与 CMS 收集器配合工作。

在 JDK 1.5 时期，HotSpot 推出了一款在强交互应用中几乎可称为划时代意义的垃圾收集器——CMS 收集器（Concurrent Mark Sweep），这款收集器是 HotSpot 虚拟机中第一款真正意义上的并发（Concurrent）收集器，它第一次实现了让垃圾收集线程与用户线程（基本上）同时工作。不幸的是它作为老年的的收集器，却无法与 JDK 1.4.0 中已经存在的新生代收集器 Parallel Scavenge 配合工作，所以在 JDK 1.5 中使用 CMS 来收集老年代的时候，新生代只能选择 ParNew 或者 Serial 收集器中的一个。

ParNew 收集器也是使用 - XX:+UseConcMarkSweepGC 选项后的默认新生代收集器，也可以使用 - XX:+UseParNewGC 选项来强制指定它。

ParNew 收集器在单 CPU 的环境中绝对不会有比 Serial 收集器更好的效果，甚至由于存在线程交互的开销，该收集器在通过超线程技术实现的两个 CPU 的环境中都不能百分之百的保证超越 Serial 收集器。当然，随着可以使用的 CPU 的数量相同，在 CPU 非常大（譬如 32 各，现在 CPU 动辄就 4 核加超线程，服务器超过 32 个逻辑 CPU 的情况越来越多了）的环境下，可以使用 - XX:ParallelGCThreads 参数来限制垃圾收集的线程数。

并发和并行这两个名词都是并发编程中的概念，在谈论垃圾收集器的上下文语境中，他们可以解释为：

• 并行（Parallel）：指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态。
• 并发（Concurrent）：指用户线程与垃圾收集线程同时运行（但不一定是并行的，也可能会交替执行），用户程序继续运行，而垃圾收集程序运行于另一个 CPU 上。

Parallel Scavenge 收集器

Parallel Scavenge 收集器也是一个新生代收集器，它也是使用复制是算法的收集器，又是并行的多线程收集器…… 看上去和 ParNew 都一样，那它有什么特别之处呢？

Parallel Scavenge 收集器的特点是它的关注点与其他收集器不同，CMS 等收集器的关注点尽可能地缩短垃圾收集时用户线程的停顿时间，而 Parallel Scavenge 收集器的目标则是达到一个可控制的吞吐量（Throughput）。所谓吞吐量就是 CPU 用于运行用户代码的时间与 CPU 总消耗时间的比值，即吞吐量 = 运行用户代码时间 / (运行用户代码时间 + 垃圾收集时间)，虚拟机总共运行了 100 分钟，其中垃圾收集花掉 1 分钟，那吞吐量就是 99%。

停顿时间越短就越适合需要与用户交互的程序，良好的响应速度能提升用户的体验；而高吞吐量则可以最高效率地利用 CPU 时间，尽快地完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。

Parallel Scavenge 收集器提供了两个参数用于精确控制吞吐量，分别是控制最大垃圾收集停顿时间的 -XX:MaxGCPauseMillis 参数及直接设置吞吐量大小的 -XX:GCTimeRatio 参数。

MaxGCPauseMillis 参数允许的值是一个大于 0 的毫秒数，收集器将尽力保证内存回收花费的时间不超过设定值。不过大家不要异想天开地认为如果把这个参数的值设置得稍小一点就能使得系统的垃圾收集速度变得更快，GC 停顿时间缩短是以牺牲吞吐量和新生代空间来换取的：系统把新生代调小一点，收集 300MB 新生代肯定比收集 500MB 快吧，这也直接导致垃圾收集发生得更频繁一些，原来 10 秒收集一次、每次停顿 100 毫秒，现在变成 5 秒收集一次、每次停顿 70 毫秒。停顿时间的确在下降，但吞吐量也降下来了。

GCTimeRatio 参数的值应当是一个大于 0 小于 100 的整数，也就是垃圾收集时间占总时间的比率，相当于是吞吐量的倒数。如果把此参数设置为 19，那允许的最大 GC 时间就占总时间的 5%（即 1 / (1 + 19) ），默认值为 99，就是允许最大 1%（即 1 / ( 1 + 99 ) ）的垃圾收集时间。

由于与吞吐量关系密切，Parallel Scavenge 收集器也经常被称为 “吞吐量优先” 收集器。除上述两个参数之外，，Parallel Scavenge 收集器还有一个参数 -XX:+UseAdaptiveSizePolicy 值得关注。这是一个开关参数，当这个参数打开之后，就不需要手工指定新生代的大小（-Xmn）、Eden 与 Survivor 区的比例（-XX:SurivorRatio）、晋升老年代对象年龄（-XX:PretenureThreshold）等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调节这些参数以提供最合适的停顿时间或最大的吞吐量，这种调节方式称之为 GC 自适应的调节策略（GC Ergonomics）。自适应调节策略也是 Parallel Scavenge 收集器与 ParNew 收集器的一个重要区别。

Serial Old 收集器

Serial Old 是 Serial 收集器的老年代版本，它同样是一个单线程收集器，使用 “标记—整理” 算法。和这个收集器的主要意义也是被 Client 模式下的虚拟机使用。如果在 Server 模式下，它主要还有两大用途：一个是在 JDK 1.5 以及之前的版本中与 Parallel Scavenge 收集器搭配使用，另一个就是作为 CMS 收集器的后备预案，在并发收集发生 Concurrent Mode Failure 的时候使用。

Serial / Serial Old 收集器的工作过程如下图：

Parallel Old 收集器

Parallel Old 是 Parallel Scavenge 收集器的老年代版本，使用多线程和 “标记—整理” 算法。

这个收集器是在 JDK 1.6 中才开始提供的，在此之前，新生代的 Parallel Scavenge 收集器一直处于比较尴尬的状态。原因是，如果新生代选择了 Parallel Scavenge 收集器，老年代除了 Serial Old（PS MarkSweep）收集器外别无选择。由于单线程的老年代 Serial Old 收集器在服务端应用性能上的 “拖累”，即使使用了 Parallel Scavenge 收集器也未必能在整体应用上获得吞吐量最大化的效果，又因为老年代收集中无法充分利服务器多 CPU 的处理能力，在老年代很大而且硬件比较高级的环境中，这种组合的吞吐量甚至还不一定有 ParNew 加 CMS 的组合 “给力”。

直到 Parallel Old 收集器出现后，“吞吐量优先” 收集器终于有了比较名副其实的应用组合，在注重吞吐量及 CPU 资源敏感的场合，都可以优先考虑 Parallel Scavenge 加 Parallel Old 收集器。

Parallel Scavenge / Parallel Old 收集器的工作过程如下图：

CMS 收集器

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的 Java 应用都集中在互联网站或 B/S 系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验，CMS 收集器就非常符合这类应用需求。

从名字（包含 “Mark Sweep”）上就可以看出 CMS 收集器是基于“标记—清除” 算法实现的，它的运作过程相对于前面几种收集器来说要更复杂一些，整个过程分为 4 个步骤：

1. 初始标记（CMS initial mark）
2. 并发标记（CMS concurrent mark）
3. 重新标记（CMS remark）
4. 并发清除（CMS concurrent sweep）

其中初始标记、重新标记着两个步骤仍然需要 “Stop The World”。初始标记仅仅只是标记一下 GC Root 能直接关联到的对象，速度很快，并发标记阶段就是进行 GC Roots Tracing 的过程，这个阶段紧随初始标记阶段，在初始标记的基础上继续向下追溯标记，而重新标记阶段则是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短，并发清理阶段清理垃圾对象，这个阶段收集器线程和应用程序线程并发执行，并发重置 这个阶段，重置CMS收集器的数据结构，等待下一次垃圾回收。

由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，所以，从总体上来说，CMS 收集器的内存回收过程是与用户线程一起并发执行的。通过下图可以比较清楚地看到 CMS 收集器的运作步骤中并发和需要停顿的时间。

CMS 是一款优秀的收集器，它的主要优点在名字上已经体现出来了：并发收集、低停顿。但是 CMS 还远达不到完美的程度，它有以下 3 个明显的缺点：

• CMS 收集器对 CPU 资源非常敏感。面向并发设计的程序都对 CPU 资源比较敏感。在并发阶段，它虽然不会导致用户线程停顿，但是会因为占用了一部分线程（或者说 CPU 资源）而导致应用程序变慢，总吞吐量会降低。CMS默认启动的回收线程数是（CPU数+3）/ 4，当 CPU 不足 4 个（譬如 2 个）时，CMS 对用户程序的影响就可能变得很大，如果本来 CPU 负载就比较大，还分出一半的运算能力去执行收集器线程，就可能导致用户程序的执行速度忽然降低了 50%，其实也让人无法接受。
• CMS 收集器无法处理浮动垃圾（Floating Garbage，由于 CMS 并发清理阶段用户线程还在运行着，伴随着程序运行自然就还会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS 无法在当次收集中处理掉它们，只好留待下一次 GC 时再清理掉。这部分垃圾就称为 “浮动垃圾”）。由于垃圾收集阶段用户线程还需要运行，就需要预留足够的内存空间给用户线程使用，因此 CMS 收集器不能像其他收集器一样等到老年代几乎完全被填满了再进行收集。在 JDK 1.6 中 CMS 收集器当老年代使用了 92% 的空间后就会被激活，可以通过 - XX:CMSInitiatingOccupancyFraction 参数来设置。如果预留的内存无法满足程序需要，就会出现“Concurrent Mode Failure” 失败，这时会临时启用 Serial Old 收集器来重新进行老年代的垃圾收集，这样停顿时间就很长了。
• CMS 是一款基于 “标记—清除” 算法实现的收集器（内存整理过程是无法并发的），这意味着收集结束时会有大量空间碎片产生，往往会出现老年代还有很大空间剩余，但无法找到足够大的连续空间来分配当前对象，不得不提前触发一次 Full GC。

G1 收集器

G1（Garbage-First）是一款面向服务端应用的垃圾收集器。

在 G1 之前的其他收集器进行收集的范围都是整个新生代或者老年代，而 G1 不再是这样。使用 G1 收集器时，Java 堆的内存布局就与其他收集器有很大差别，它将整个 Java 堆划分为多个大小相等的独立区域（Region），虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，它们都是一部分 Region（不需要连续）的集合。

与其他 GC 收集器相比，G1 具备以下特点：

• 并行与并发：G1 能充分利用多 CPU、多核环境下的硬件优势，使用多个 CPU（CPU 或者 CPU 核心）来缩短 Stop The World 停顿的时间。
• 分代收集：与其他收集器一样，分代概念在 G1 中依然得以保留。虽然 G1 可以不需要其他收集器配合就能独立管理整个 GC 堆。
• 空间整合：与 CMS 的 “标记—清除” 算法不同，G1 从整体来看是基于 “标记—整理” 算法实现的收集器，从局部（两个 Region 之间）上来看是基于 “复制” 算法实现的。但无论如何，这两个算法都意味着 G1 运作期间不会产生内存空间碎片，收集后能提供规整的可用内存。
• 可预测的停顿：这个 G1 相对于 CMS 的另一大优势，降低停顿时间是 G1 和 CMS 共同关注点，但 G1 除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为 M 毫秒的时间片段内，消耗在垃圾收集上的时间不得超过 N 毫秒，这几乎已经是实时 Java（RTSJ）的垃圾收集器的特征了。

G1 收集器之所以能建立可预测的停顿时间模型，是因为它可以有计划地避免在整个 Java 堆进行全区域的垃圾收集。G1 跟踪各个 Region 里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的 Region。这种使用 Region 划分内存空间以及有优先级的区域回收方式，保证了 G1 收集器在有限的时间内可以获取尽可能高的收集效率。

G1 收集器的运作大致可划分为以下几个步骤：

1. 初始标记（Initial Marking）
2. 并发标记（Concurrent Marking）
3. 最终标记（Final Marking）
4. 筛选回收（Live Data Counting and Evacuation）

G1 前几个步骤的运作过程和 CMS 有很多相似之处。

初始标记阶段仅仅只是标记一下 GC Roots 能直接关联到的对象，并且修改 TAMS（Nexr Top at Mark Start）的值，让下一阶段用户程序并发运行时，能在正确可用的 Region 中创建新对象，这阶段需要停顿线程，但耗时很短。

并发标记阶段是从 GC Roots 开始对堆中对象进行可达性分析，找出存活的对象，这阶段耗时较长，但可以与用户并发执行。

最终标记阶段是为了修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录，这阶段需要停顿线程，但是可并行执行。

最后在筛选回收阶段首先对各个 Region 的回收价值和成本进行排序，根据用户所期望的 GC 停顿时间来制定回收计划。从 Sun 公司透露出来的信息来看，这个阶段其实也是可以做到与用户程序一起并发执行，但是因为只回收一部分 Region，时间是用户可控制的，而且停顿用户线程将大幅度提高收集效率。

内容源自：深入理解Java虚拟机

                  http://qsxuan.com/articles/1053.html