深入理解Java虚拟机（6）——垃圾收集器

一.垃圾收集器种类

新年代：（1）Serial （2） ParNew         （3）Parallel Scavenge 

老年代：（1）CMS   （2）Serial Old（MSC）（3）Parallel Old

新年代和老年代：G1

1.Serial收集器：一个单线程的收集器，它在进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束。

优点：简单高效，对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集可以获得最高的单线程收集效率。

缺点：在用户不可见的情况下把用户正常工作的线程全部停掉。

Serial/Serial Old收集器运行示意图：

（1）新生代采取复制算法暂停所有用户线程。

（2）老年代采用标记—整理算法暂停所有用户线程。

2.ParNew收集器

 ParNew收集器是Serial收集器的多线程版本。

 两个重要的概念：

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

并发：用户线程与垃圾收集线程同时执行，用户程序在继续运行，而垃圾收集程序运行于另一个CPU上。

3.Parallel Scavenge收集器（使用复制算法的新生代收集器）

Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量。

吞吐量：CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间），虚拟机总共运行了100分钟，其中垃圾收集花掉1分钟，吞吐量就是99%。

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

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

4.CMS收集器

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

    CMS收集器是基于“标记—清除”算法实现的。

包括：

    （1）初始标记

    （2）并发标记

    （3）重新标记

    （4）并发清除

    初始标记、重新标记仍然需要“Stop the world”。初始标记是标记一下GC Roots能直接关联到的对象，速度很快。并发标记阶段就是进行GC Roots Tracing的过程，而重新标记阶段则是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录。

    由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作。所以，CMS收集器的内存回收过程是与用户线程一起并发执行的。

    CMS是一款优秀的收集器，主要优点是：并发收集、低停顿——低停顿并发收集器。

缺点：

（1）.CMS收集器对CPU资源非常敏感，面向并发设计的程序都对CPU资源比较敏感。在并发阶段，它不会导致用户线程停顿，但是会因为占用一部分线程而导致应用程序变慢，总吞吐量会降低。CMS默认启动的回收线程数是（CPU数量+3）/4，当CPU在4个以上时，并发回收时垃圾收集线程不少于25%的CPU资源，并且随着CPU数量的增加而下降。当CPU不足4个时，CMS对用户程序的影响就可能变得更大，如果本来CPU负载就比较大，还分出一半的运算能力去执行收集器线程，就可能导致用户程序的执行速度忽然降低50%。为了应对这种情况，增加了一种称为“增量式并发收集器”的CMS收集器变种。

（2）.CMS收集器无法处理浮动垃圾（Floating Garbage），可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。

浮动垃圾：由于CMS并发清理阶段用户线程还在运行，伴随程序运行自然就还会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS无法在档次收集中处理掉他们，只好留待下一次GC时再清理。这一部分垃圾就叫做“浮动垃圾”。

    由于在垃圾收集阶段用户线程还需要运行，也需要留出足够的内存空间给用户线程使用，因此CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，需要预留一部分空间提供并发收集时的程序运行使用。JDK1.5的默认设置下，CMS收集器当老年代使用了68%的空间后就会被激活。可以适当调高参数-XX：CMSInitiatingOccupancyFaction的值来提高触发百分比，以便降低内存回收次数从而获取更好的性能。-XX：CMSInitiatingOccupancyFaction太高容易导致大量“Concurrent Mode Fialure”失败，性能反而降低。

（3）CMS是基于“标记—清除”算法实现的收集器。收集结束的时候会有大量空间碎片产生。空间碎片太多，将会给大对象分配带来很大麻烦，往往会出现老年代还有很大空间剩余，但是无法找到足够大的连续空间来分配当前对象，不得不提前出发一次Full GC。CMS收集器提供了一个-XX：+UseCMSCompactAtFullCollection时开启内存碎片的合并整理过程，内存整理的过程是无法并发的，导致停顿时间不得不变长。

5.G1收集器（重点）

G1是一款面向服务端应用的垃圾收集器v。

特点：

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

（2）分代收集：与其他收集器一样，分代概念在G1中依然得以保留。

（3）空间整合：与CMS的“标记—清理”算法不同，G1从整体来看是基于“标记—整理”算法实现的收集器，从局部上来看是基于“复制”算法实现的，都意味着G1运作期间不会产生内存空间碎片，收集后能提供规整的可用内存。特性有利于程序长时间运行，分配大对象时不会因为无法找到连续内存空间而提前触发下一次GC。

（4）可预测的停顿：降低停顿时间是G1和CMS共同的关注点，但G1除了追求停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒，这几乎已经是实时Java的垃圾收集器的特征。

    使用G1收集器时，将整个Java堆划分为多个大小相等的独立区域，虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，都是一部分Region的集合。

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

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

    G1收集器的运作大致可划分为：

（1）初始标记

（2）并发标记

（3）最终标记

（4）筛选回收

  初始标记阶段标记GC Roots能直接关联到的对象，并且修改TAMS（Next Top at Mark Start）的值，让下一阶段用户程序并发运行时，能在正确可用的Region中创建对象，这阶段需要停顿线程，但耗时很短。并发标记阶段是从GC Roots开始对堆中对象进行可达性分析，找出存活对象，耗时较长，但可与用户线程并发执行。最终标记是为了修正在并发标记期间因用户线程继续运作而导致标记产生变动的那一部分标记记录，虚拟机将这段时间对象变化记录在线程Remembered Set Logs里面，最终标记阶段需要Remembered Set Logs的数据合并到Remembered Set中，这阶段停顿线程，但是可并行执行。最后在筛选回收阶段首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划，这个阶段其实也可以做到与用户程序一起并发执行，但是因为回收一部分Region，时间是用户控制的，而且停顿用户线程将大幅提供收集效率。