垃圾收集器与内存分配策略(四)——垃圾收集器

垃圾收集器介绍

在垃圾收集器的层面上对并行与并发的解释：
并行（Parallel）：指多条垃圾收集线程并行工作，但此时用户现场仍处于等待状态。
并发（Concurrent）：指用户线程与垃圾收集线程同时执行（但并不一定是并行的，可能会交替执行），用户程序仍在继续执行，而垃圾收集程序运行于另一个CPU上。
对于不同的厂商，不同的版本的虚拟机都可能有很大的差别。此处讨论的是jdk1.7之后的HotSpot虚拟机，如下图所示：

Serial收集器

Serial/Serial Old收集器的运行过程如下图所示：

Serial收集器的特点：

1. 最基本，发展历史最悠久的收集器（jdk1.3.1之前是虚拟机新生代唯一的选择）
2. 是一个单线程的收集器，它的“单线程”不仅仅指它只会使用一个CPU或一条收集线程去完成垃圾收集工作，更重要的是它进行垃圾收集时必须暂停其它所有的工作线程，直到它收集结束。
3. 在用户并不可见的情况下把用户正常工作的线程全部停掉，由虚拟机在后台自动发起和自动完成。（当然随着其它收集器的出现，用户线程的停顿时间在不断缩短，但仍然没办法完全消除）

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

Serial收集器的特应用：
Serial是虚拟机运行在Client模式下的默认新生代收集器。

ParNew收集器

ParNew收集器其实就是Serial收集器的多线程版本，除了使用多条线程进行垃圾收集之外，其余行为与Serial收集器完全一样。
ParNew收集器的运行过程如下图所示：

ParNew收集器的特点：

1. ParNew收集器除了多线程收集之外，其它与Serial收集器并没有太多创新之处。
2. ParNew收集器在单CPU的环境下绝对不会有比Serial收集器更好的效果。（甚至在二个CPU的环境中由于线程交互的开销，都不能100%保证超过Serial收集器）

ParNew收集器的应用：
运行在server模式下的虚拟机首选的新生代收集器。（一个与性能无关的重要原因是除了Seria就只有ParNewl能与CMS收集器配合工作）

Parallel Scavenge收集器

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

Parallel Scavenge收集器的特点：

1. Parallel Scavenge收集器的目的是达到一个可控制的吞吐量（Throughput）而其他收集器目的是尽可能缩短垃圾收集时用户线程的停顿时间（如CMS等收集器）。
2. “吞吐量优先”的收集器，吞吐量即运行用户代码的时间 / （垃圾收集时间+运行用户代码时间）。
3. Parallel Scavenge收集器提供了二个参数用于精确控制吞吐量。
   控制最大垃圾收集时间：-XX:MaxGCPauseMillis(大于0的毫秒数)。通过调小新生代空间大小，提高垃圾收集频率来使垃圾收集停顿时间下降，但同时也降低了吞吐量。
   直接设置吞吐量大小：-XX：GCTimeRatio（0-100的整数）。垃圾收集时间占总时间的比率，相当于吞吐量的倒数，参数默认值为99。如将参数设置为19，则允许最大的垃圾收集时间占总时间的1 / （1+ 19）即5%。
4. GC自适应调节策略：Parallel Scavenge收集器通过设置-XX：+UseAdaptiveSizePolicy这个开关参数，虚拟机通过当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或最大的吞吐量。
   设置步骤为：先设置基本内存数据（如：-Xmx设置最大堆），然后给虚拟机一个优化目标MaxGCPauseMillis参数（关注最大垃圾收集停顿时间）或GCTimeRatio参数（关注吞吐量）即可，最后具体细节参数由虚拟机自动完成。

Parallel Scavenge收集器的适用场景：
高吞吐量则可以高效的利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。

Serial Old收集器

Serial Old是一个单线程、使用”标记-整理“算法、Serial的老年代版本的收集器。Serial/Serial Old收集器的运行过程如下图所示：

Serial Old收集器的使用场景：

1. Serial Old可以在Client模式下的虚拟机使用
2. Serial Old可以与Parallel Scavenge搭配使用
3. Serial Old可以作为CMS收集器的后备方案在并发收集时发生Concurrent Mode Failure时使用

1.5、 Parallel Old收集器

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

Parallel Old收集器适用场景：注重吞吐量及CPU资源敏感的场合。

CMS收集器

在jdk1.5时期，HotSpot推出了CMS收集器，这是HotSpot虚拟机中第一款真正意义上的并发收集器，他第一次实现了让垃圾收集线程与用户线程（基本上）同时工作。
CMS（Concurrent Mark Sweep）:并发标志清除收集器是一种以获取最短回收停顿时间为目标的收集器。工作过程如下图：

CMS收集器使用的是“标记—清除算法”，整个过程分为4步：

1. 初始标记（CMS initial mark）：只标记GC roots能直接关联到的对象，速度很快。
2. 并发标记（CMS concurrent mark）：进行GC Roots Tracing的过程。
3. 重新标记（CMS remark）：修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录。重新标记的标记时间比初始标记时间稍长，但远比并发标记时间短。
4. 并发清除（CMS concurrent sweep）

其中初始标记及重新标记仍然需要“stop the world”，但总体时间较短。而耗时较长的并发标记及并发清除可以与用户线程一起工作。所以总体上来说CMS收集器的内存回收是与用户线程一起执行的。

CMS收集器的优点：并发收集、低停顿。
CMS收集器的缺点：

1. CMS收集器对CPU资源敏感，在并发阶段虽然不会导致用户线程停顿，但是因为占用了一部分CPU资源会导致应用程序变慢，总吞吐量降低。
2. CMS收集器无法处理浮动垃圾（并发运行时，用户程序运行时产生的垃圾），可能导致“Concurrent Model Failure”失败而导致另一次Full GC的产生。同时由于内存回收线程与用户线程同时运行，在垃圾回收时不能等老年代空间快满了时进行回收，必须为用户线程的运行预留一部分空间。若预留的内存无法满足用户程序的需要就会出现“Concurrent Model Failure”失败，这是虚拟机将临时采用Serial Old收集器进行收集，导致停顿时间变很长。
3. 空间碎片太多，给大对象分配空间时找不到足够大的连续空间来分配当前对象，而提前触发一次Full GC。为了解决这个问题，提供了二个参数
   -XX：UseCMSCompactAtFullCollection开关参数（默认开启），用于在顶不住要进行Full GC时进行内存碎片整理（不能并发，停顿时间变长）；
   -XX：CMSFullGCsforeCompaction用于设置执行多少次不压缩的Full GC后带来一次压缩的（默认为0，表示每次进入Full GC都进行碎片整理）。

CMS的适用场景：
集中在互联网站或者B/S系统的服务端上，重视服务的响应速度，以带给用户较好的体验。

G1收集器

G1（Garbage-First)收集器是一款面向服务端应用的垃圾收集器。使用G1收集器时，它将Java堆分成多个大小相等的独立区域（Region）,新生代与老年代不在物理相隔了，它们都是一部分Region（不需要连续）的集合。工作过程如下图：

G1收集器的特点：

1. 并行与并发：充分利用多CPU、多核环境下的硬件优势来缩短“stop-the-world”的时间。
2. 分代收集：不需要其他收集器的配合，就能独立管理整个GC堆，但也能采用不同的方式对不同阶段的对象（新创建的、存活了一段时间的，经过多次GC的旧对象）进行收集。
3. 空间整合：整体基于“标记-整理”算法；局部（二个Region）之间采用“复制”算法。都不会产生内存空间碎片。
4. 可预测的停顿：能让使用者指定在一个长度为M毫秒的时间片段内，垃圾收集消耗的时间在N毫秒内。（之所以能建立可预测的时间停顿模型在于G1避免了在整个Java堆中进行全区域的垃圾回收；G1跟踪每个Region里面的垃圾堆积的价值大小（时间、空间），维护一个优先列表，根据允许的收集时间优先选择回收价值大的Region。）

为了避免因为Region之间存在引用，从而在进行可达性分析判断对象是否存活时进行整个Java堆全堆扫描，G1中每个Region都有一个对应的Remenbered Set来记录区域之间对象的引用信息，它的工作过程如下：

1. 虚拟机发现程序在对Reference进行写操作时，产生一个Write Barrier暂时中断写操作
2. 检查Referrence引用的对象是否在不同的Region中（在分代收集中即判断是否老年代的对象引用了新生代的对象）
3. 如果是在不同的Region之间，便通过CardTable把相关的引用信息记录到被引用对象所属的Region的Remenbered Set中
4. 进行内存回收时，在GC Roots枚举范围中中加入Remenbered Set即可保证不对全堆扫描也不会有遗漏

G1收集器的工作步骤（不考虑Remenbered Set的维护操作）：

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