Java 垃圾收集之垃圾收集器介绍

垃圾收集器

并行与并发

垃圾收集器有并行、并发的，解释一下这两个名词：

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

垃圾收集器是内存回收的具体实现，HotSpot 虚拟机包含的收集器如图：

上图中有7种作用于不同分代的收集器，如果两个收集器之间存在连线，说明它们可以搭配使用，其中 Young generation 代表新生代，Tenured generation 代表老年代。下面介绍一下这几种收集器。

Serial 收集器

Serial 收集器是最基本，历史最悠久的收集器。这个收集器是一个单线程的收集器，“单线程”的意义不只是说明它只会使用一个 CPU 或一条执行线程去完成垃圾收集工作，更重要的是在进行垃圾收集时必须暂停其它所有工作线程（Stop The World），直到它收集结束。这项工作实际上是由虚拟机在后台自动发起和自动完成的。Serial / Serial Old 收集器的运行过程如下：

虽然 Serial 收集器在进行回收时会暂停用户线程，但是它也有优于其它收集器的地方：简单高效（与其它收集器的单线程比），对于限定单个 CPU 的环境来说，Serial 收集器由于没有线程交互的开销，自然可以获得最高的单线程收集效率。Serial 收集器对运行在 Client 模式下的虚拟机来说是一个很好的选择。

ParNew 收集器

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

ParNew 收集器是许多运行在 Server 模式下的虚拟机种首选的新生代收集器，其中一个与性能无关的很重要的原因是，除了 Serial 收集器外，目前只有它能与 CMS 收集器（Concurrent Mark Sweep）配合工作。这款收集器是 HotSpot 虚拟机中第一款真正意义上的并发（Concurrent）处理器，它第一次实现了垃圾收集线程与用户线程同时工作。ParNew 收集器是使用 -XX:+UseConcMarkSweepGC 选项后的默认新生代收集器，也可以使用 -XX:+UseParNewGC 选项来强制指定它。
ParNew 收集器在单线程环境下没有 Serial 收集器效率高，随着 CPU 的数量增加，它对于 GC 时系统资源的有效利用还是很有好处的。它默认开启的收集线程数与 CPU 的数量相同，可以使用 -XX:ParallelGCThreads 参数来限制垃圾收集器的线程数。

Parallel Scavenge 收集器

Parallel Scavenge 收集器是一个新生代收集器，它也是用复制算法的收集器，又是并行的多线程收集器，和 ParNew 相比，它有什么特别之处呢？
Parallel Scavenge 收集器的特点是它的关注点与其它收集器不同，CMS 等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间，而 Parallel Scavenge 收集器的目标则是达到一个可控制的吞吐量（Throughput）。所谓吞吐量就是 CPU 运行用户代码的时间与 CPU 总消耗时间的比值，即吞吐量 = 运行用户代码时间 / （运行用户代码时间 + 垃圾收集时间）。
高吞吐量可以高效利用 CPU 时间，尽快完成程序的运算任务，适合在后台运算而不需要太多交互的任务。
Parallel Scavenge 收集器提供了两个参数控制吞吐量，分别是控制最大垃圾收集停顿时间的 -XX:MaxGCPauseMillis 参数以及直接设置吞吐量大小的 -XX:GCTimeRatio 参数。此外，Parallel Scavenge 收集器还有一个参数 -XX:+UseAdaptiveSizePolicy，这个参数打开之后，就不需要手工指定新生代的大小（-Xmn）、Eden 与 Survivor 区的比例（-XX:SurvivorRatio）、晋升老年代对象年龄（-XX:PretenureSizeThreshold）等细节参数了，虚拟机会根据当前系统运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或最大吞吐量，这种调节方式称为 GC 自适应的调节策略（GC Ergonomics）。

Serial Old 收集器

Serial Old 收集器是 Serial 收集器的老年代版本，同样是一个单线程收集器，使用“标记-整理”算法。主要是给 Client 模式下的虚拟机使用。在 Server 模式下主要有两大用途：一种是在 JDK 1.5 以及之前的版本与 Parallel Scavenge 收集器搭配使用，另一种用途就是作为 CMS 收集器的后备方案，在并发收集发生 Concurrent Mode Failure 时使用。Serial Old 收集器工作过程同 Serial 收集器。

Parallel Old 收集器

Parallel Old 是 Parallel Scavenge 收集器的老年代版本，使用多线程和“标记-整理”算法。
在注重吞吐量以及 CPU 资源敏感的场合，可以优先考虑 Parallel Scavenge + Parallel Old 收集器组合。Parallel Old 收集器工作过程如下：

CMS 收集器

CMS（Concurrent Mark Sweep）收集器是一种以收获最短回收停顿时间为目标的收集器，非常符合重视服务的响应速度，希望系统停顿时间最短这类应用的需求。
从名字（包含“Mark Sweep”）上就可以看出，CMS 收集器是基于“标记-清除”算法实现的，整个过程分为4步：

• 初始标记（CMS initial mark）
• 并发标记（CMS concurrent mark）
• 重新标记（CMS remark）
• 并发清除（CMS concurrent sweep）

其中，初始标记、重新标记这两个步骤仍然需要“Stop The World”。初始标记仅仅只是标记一下 GC Roots 能直接关联到的对象，速度很快，并发标记阶段就是进行 GC Roots Tracing 的过程，而重新标记阶段则是为了修正并发标记期间因用户程序继续运作而导致标记产生变动那一部分对象的标记记录。
由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，所以总体上来说 CMS 收集器的内存回收过程是与用户线程一起并发执行的。CMS 收集器运行过程如下：

CMS 收集器是一款优秀的收集器：并发收集、低停顿。但是也存在3个明显的缺点：

• CMS 收集器对 CPU 资源非常敏感，工作时会因为占用 CPU 资源导致应用程序缓慢，总吞吐量降低。CMS 默认启动的线程数是（CPU 数量 + 3）/ 4，也就是 CPU 在4个以上时，并发回收时垃圾收集线程不少于25%的CPU资源，并且伴随着 CPU 数量的增加而下降。但是当 CPU 数量不足4个时，CMS 对用户程序的影响就可能变得很大。
• CMS 收集器无法处理浮动垃圾（Floating Garbage），可能出现“Concurrent Mode Failure” 失败而导致另一次 Full GC 的产生。由于 CMS 并发清理阶段用户线程还在运行着，这样会有新垃圾不断产生，这部分垃圾出现在标记过程之后，CMS 无法在当此收集中处理掉他们，只好等下一次 GC 时再清理掉。这部分垃圾就是“浮动垃圾”。另外，由于垃圾收集阶段用户线程还需要执行，所以还需要预留足够空间给用户线程使用，因此 CMS 收集器需要预留一部分空间提供并发收集时的程序运作使用。可以使用 -XX:CMSInitiatingOccupancyFraction 来指定老年代使用多少空间（百分比）后被激活。如果 CMS 运行期间预留的内存无法满足程序需要，就会出现一次“Concurrent Mode Failure”失败，这时虚拟机将启动后备方案：临时启用 Serial Old 收集器来重新进行老年代的垃圾收集，这样停顿时间就很长了。所以参数设置太高容易导致大量“Concurrent Mode Failure”失败，性能反而降低。
• 由于 CMS 是一款基于“标记-清除”算法实现的收集器，所以收集结束后会产生大量空间碎片，当有大对象分配时连续空间不足而触发一次 Full GC。CMS 收集器提供了一个 -XX:+UseCMSCompactAtFullCollection 开关参数（默认开启），用于在 CMS 收集器顶不住要进行 Full GC 时开启内存碎片的合并整理过程。

G1 收集器

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

• 并行与并发：G1 能充分利用多 CPU、多核环境下的硬件优势，使用多个 CPU 来缩短 Stop-The-World 停顿的时间，部分其它收集器原本需要停顿 Java 线程执行的 GC 动作，G1 收集器仍然可以通过并发的方式让 Java 程序继续执行。
• 分代收集：虽然 G1 可以不需要与其它收集器配合就能独立管理整个 GC 堆，但它能够采用不同方式去处理新创建的对象和已存活了一段时间、熬过多次 GC 的旧对象以获取更好的收集效果。
• 空间整合：与 CMS 的“标记-清除”算法不同，G1 从整体来看是基于“标记-整理”算法实现的收集器，从局部（两个 Region 之间）上来看是基于“复制”算法实现的。无论如何都不会产生内存空间碎片。
• 可预测的停顿：这是 G1 相对于 CMS 来说的另一大优势，G1 除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为 M 毫秒的时间片段内，消耗在垃圾收集上的时间不得超过 N 毫秒，这几乎已经是实时 Java（RTSJ）的垃圾收集器的特征了。

在 G1 之前的其它收集器进行收集的范围都是整个新生代或者老年代，而 G1 不再是这样。使用 G1 收集时，Java 堆的内存布局就与其它收集器有很大差别，它将整个 Java 堆划分为多个大小相等的独立区域（Region），虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，他们都是一部分 Region（不需要连续）的集合。
G1 之所以能建立可预测的停顿时间模型，是因为它可以有计划地避免在整个 Java 堆中进行全区域的垃圾收集。G1 跟踪各个 Region 里面的垃圾堆积的价值大小（回收可获得空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的 Region（这也是 Garbage-First 名称的来由）。这种使用 Region 划分内存空间以及有优先级的区域回收方式，保证了 G1 收集器在有限的时间内可以获取尽可能高的收集效率。
在 G1 中，Region 之间的对象引用以及其它收集器中的新生代与老年代之间的对象引用，虚拟机都是使用 Remembered Set 来避免全堆扫描的。G1 中每个 Region 都有一个与之对应的 Remembered Set，虚拟机发现程序在对 Reference 类型的数据进行写操作时，会产生一个 Write Barrier 暂时中断写操作，检查 Reference 引用的对象是否处于不同的 Region 之中（在分代中的例子就是检查老年代中的对象是否引用了新生代中的对象） ，如果是，则通过 CardTable 把相关引用信息记录到被引用对象所属的 Region 的 Remembered Set 之中。当进行内存回收时，在 GC 根节点的枚举范围中加入 Remembered Set 即可保证不对全堆扫描也不会有遗漏。
如果不计算维护 Remembered Set 的操作，G1 收集器的运作大致可分为以下几个步骤：

• 初始标记（Initial Marking）
• 并发标记（Concurrent Marking）
• 最终标记（Final Marking）
• 筛选回收（Live Data Counting and Evacuation）

G1 的前几个步骤运作过程和 CMS 有很多相似之处。
初始标记仅仅标记一下 GC Roots 能直接关联到的对象，并修改 TAMS（Next Top at Mark Start）的值，让下一阶段用户程序并发执行时，能在正确可用的 Region 中创建新对象，这阶段需要线程停顿，但耗时很短。
并发标记阶段是从 GC Root 开始对堆中对象进行可达性分析，找出存活对象，这阶段耗时较长，但可与用户程序并发执行。
最终标记阶段则是为了修改在并发标记期间因用户程序继续运作而导致标记产生变化的那部分标记记录（一个规律：并发执行的收集器一般都需要重新标记的过程），虚拟机将这段时间对象变化记录在线程 Remembered Set Logs 里面，最终标记阶段需要把 Remembered Set Logs 的数据合并到 Remembered Set 中，这阶段需要停顿线程，但是可并发执行。
筛选回收阶段首先对各个 Region 的回收价值和成本进行排序，根据用户所期望的 GC 停顿时间来制定回收计划。
G1 收集器运行过程如下：

GC 日志说明

有如下 GC 日志：
[GC (System.gc()) [PSYoungGen: 3952K->808K(75776K)] 3952K->816K(249344K), 0.0103407 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]
[Full GC (System.gc()) [PSYoungGen: 808K->0K(75776K)] [ParOldGen: 8K->710K(173568K)] 816K->710K(249344K), [Metaspace: 3420K->3420K(1056768K)], 0.0042775 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
日志开头的 “[GC” 和 “[Full GC” 说明了这次垃圾回收的停顿类型，“ [PSYoungGen”、“[ParOldGen” 代表 GC 发生的区域，方括号之内的 “3952K->808K(75776K)” 含义是 “GC 前该内存区域已使用的容量 -> GC后该内存区域已使用容量（该内存区域总容量）”。方括号之外的 “3952K->816K(249344K)” 表示 “GC 前 Java 堆已使用容量 -> GC 后 Java 堆已使用容量（Java 堆总容量）”。
“ [Times: user=0.00 sys=0.00, real=0.01 secs]” 中，user 代表用户态消耗的 CPU 时间，sys 代表内核态消耗的 CPU时间，real 代表操作从开始到结束所经过的墙钟事件（Wall Clock Time）。墙钟事件也包括各种非运算的等待耗时，如等待磁盘 I/O、等待线程阻塞等，而 CPU 时间不包括这些耗时。

垃圾收集器参数总结