垃圾收集器与内存分配策略（五）——垃圾收集器

（1）Serial收集器

Serial收集器是JDK1.3之前虚拟机新生代收集的唯一选择。这个收集器是一个单线程的收集器，单线程的意义是指在它进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束。

它的优势在于对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，可以获得最高的单线程收集效率。

（2）ParNew收集器

ParNew收集器是Serial收集器的多线程版本，也是新生代收集器。

ParNew收集器在单CPU的环境中绝对不会有比Serial收集器更好的效果。默认情况下，它默认开启的收集线程数与CPU的数量相同。

（3）Parallel Scavenge收集器

Parallel Scavenge收集器是一个新生代收集器，它也是使用复制算法的收集器，也是并行的多线程收集器。

Parallel Scavenge收集器的目标是达到一个可控制的吞吐量。所谓吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间)，虚拟机总共运行了100分钟，其中垃圾收集花掉了1分钟，那吞吐量就是99%。

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

MaxGCPauseMills参数允许的值是一个大于0的毫秒数，收集器将尽可能地保证内存回收花费的时间不超过设定值。不过并不是这个参数的值设置的小一点就能使得系统的垃圾收集速度变得更快，GC停顿时间缩短是以牺牲吞吐量和新生代空间来换取的；如果停顿时间缩小了，那吞吐量也就降下来了。

GCTimeRatio是一个大于0且小于100的整数，也就是垃圾收集时间占总时间的比率，相当于是吞吐量的倒数。

（4）Serial Old收集器

Serial Old收集器是Serial收集器的老年代版本，它同样是一个单线程收集器，使用“标记-整理”算法。

（5）Parallel Old收集器

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

（6）CMS收集器

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器，是基于“标记-清除”算法实现的。它的运作过程包括一下4个步骤：

a.初始标记

b.并发标记

c.重新标记

d.并发清除

其中初始标记、重新标记这两个步骤在进行的时候，仍然要求其他工作线程暂停。初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，并发标记阶段就是进行GC Roots Tracing的过程，而重新标记阶段则是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长些，但远比并发标记的时间短。

CMS是一款优秀的垃圾收集器，它的主要优点是并发收集，低停顿。但也有如下缺点：

a.CMS收集器对CPU资源非常敏感。在并发阶段，它虽然不会导致用户线程停顿，但是会因为占用了一部分CPU资源而导致应用程序变慢，总吞吐量会降低。

b.CMS收集器无法处理浮动垃圾。由于CMS并发清理阶段用户线程还在运行着，伴随程序运行自然就还会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS无法在当次收集中处理掉它们，只好留待下一次GC时再清理掉。这一部分就称为“浮动垃圾”。也是由于在垃圾收集阶段用户线程还需要运行，那也就还需要预留足够的内存空间给用户线程使用，因此CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，需要预留一部分空间提供并发收集时的程序运作使用。

c.CMS收集器是基于“标记-清除”算法实现的收集器，这就意味着收集结束时会有大量空间碎片产生。

（7）G1收集器

G1是一款面向服务端应用的垃圾收集器。与其他GC收集器相比，G1具备如下特点：

a.并行与并发：G1能充分利用多CPU、多核环境下的硬件优势，使用多个CPU来缩短停顿时间，部分其他收集器原本需要停顿java线程的GC动作，G1收集器仍然可以通过并发的方式让java程序继续执行。

b.分代收集：G1可以不需要其他收集器配合就能独立管理整个GC堆，但它能够采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获取更好的收集效果。

c.空间整合：G1从整体上来看是基于“标记-整理”算法实现的收集器，从局部上来看是基于“复制”算法实现的，但无论如何，这两种算法都意味着G1运作期间不会产生内存空间碎片，收集后能提供规整的可用内存。

d.可预测的停顿：G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒。

使用G1收集器，java堆的内存布局就与其他收集器有很大区别，它将整个java堆划分为多个大小相等的独立区域，虽然还保留新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，它们都是一部分独立区域的集合。

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

G1把内存“化零为整”的思路，理解起来似乎很容易，但其中的实现细节却远远没有想象中那样简单。把java堆分为多个独立区域后，垃圾收集是否就真的能以独立区域为单位进行了？听起来顺理成章，但是仔细想想就发现问题所在了：独立区域不可能是孤立的。一个对象分配在某个独立区域，它并非只能被独立区域中的其他对象引用，而是可以与整个java堆任意的对象发生引用关系。那在做可达性判定确定对象是否存活的时候，岂不是还得扫描整个java堆才能保证准确性。这个问题并非在G1中才有，只是在G1中更加突出。在以前的分代收集中，新生代的规模一般都比老年代要小许多，新生代的收集也比老年代要频繁许多，那回收新生代中的对象时也面临相同的问题，如果回收新生代时也不得不同时扫描老年代的话，那么GC的效率可能下降不少。

在G1收集器中，独立区域之间的对象引用以及其他收集器中的新生代与老年代之间的对象引用，虚拟机都是使用Remembered Set来避免全堆扫描的。G1中每个独立区域都有一个与之对应的Remembered Set，虚拟机发现程序在对Reference类型的数据进行写操作时，会产生一个Write Barrier暂时中断写操作，检查Reference引用的对象是否处于不同的独立区域之中（在分代的例子中就是检查是否老年代中的对象引用了新生代中的对象），如果是，便通过CardTable把相关引用信息记录到被引用对象所属的独立区域的Remembered Set之中。当进行内存回收时，在GC根节点的枚举范围中加入Remembered Set即可保证不对全堆扫描也不会有遗漏。

参考文档：《深入理解java虚拟机》周志明著

上一篇：垃圾收集器与内存分配策略（四）——HotSpot的算法实现

下一篇：垃圾收集器与内存分配策略（六）——内存分配与回收策略