《深入理解 Java 虚拟机 JVM 高级特性与最佳实践(第3版)》_求知之路漫漫_3.5.7 Garbage First收集器

【摘要】 本书摘自《深入理解 Java 虚拟机 JVM 高级特性与最佳实践(第3版)》一书中第3章，第5节，周志明著。

3.5.7 Garbage First收集器

Garbage First (简称G1) 收集器是垃圾收集器技术发展历史上的里程碑式的成果，它 开创了收集器面向局部收集的设计思路和基于Region 的内存布局形式。早在JDK 7刚刚 确立项目目标、Oracle 公司制定的JDK 7 RoadMap里 面 ，G1 收集器就被视作JDK7 中 HotSpot 虚拟机的一项重要进化特征。从JDK6 Update 14 开始就有 Early Access 版本的G1 收集器供开发人员实验和试用，但由此开始G1 收集器的“实验状态”(Experimental) 持 续了数年时间，直至JDK 7 Update 4,Oracle 才认为它达到足够成熟的商用程度，移除了 “Experimental” 的标识；到了JDK8 Update 40的时候， G1 提供并发的类卸载的支持，补 全了其计划功能的最后一块拼图。这个版本以后的G1 收集器才被Oracle 官方称为“全功 能的垃圾收集器”(Fully-Featured Garbage Collector)。

G1 是一款主要面向服务端应用的垃圾收集器。HotSpot 开发团队最初赋予它的期望是 (在比较长期的)未来可以替换掉 JDK 5中发布的 CMS 收集器。现在这个期望目标已经实 现过半了， JDK9 发布之日，G1 宣告取代Parallel Scavenge 加 Parallel Old 组合，成为服 务端模式下的默认垃圾收集器，而CMS 则沦落至被声明为不推荐使用 (Deprecate) 的收集 器°。如果对JDK9 及以上版本的HotSpot 虚拟机使用参数-XX:+UseConcMarkSweepGC 来开启 CMS 收集器的话，用户会收到一个警告信息，提示CMS 未来将会被废弃：

Java HotSpot(TM) 64-Bit Server VM warning: Option UseConcMarkSweepGC was

deprecated in version 9.0 and will likely be removed in a future release.

但作为一款曾被广泛运用过的收集器，经过多个版本的开发迭代后，CMS (以及之前 几款收集器)的代码与 HotSpot 的内存管理、执行、编译、监控等子系统都有千丝万缕的联系，这是历史原因导致的，并不符合职责分离的设计原则。为此，规划JDK10 功能目标 时 ，HotSpot 虚拟机提出了“统一垃圾收集器接口”日，将内存回收的“行为”与“实现” 进行分离，CMS 以及其他收集器都重构成基于这套接口的一种实现。以此为基础，日后要 移除或者加入某一款收集器，都会变得容易许多，风险也可以控制，这算是在为CMS 退出 历史舞台铺下最后的道路了。

作为CMS 收集器的替代者和继承人，设计者们希望做出一款能够建立起“停顿时间模 型”(Pause Prediction Model) 的收集器，停顿时间模型的意思是能够支持指定在一个长度为 M 毫秒的时间片段内，消耗在垃圾收集上的时间大概率不超过N 毫秒这样的目标，这几乎 已经是实时Java(RTSJ) 的中软实时垃圾收集器特征了。

那具体要怎么做才能实现这个目标呢?首先要有一个思想上的改变，在G1 收集器出现 之前的所有其他收集器，包括CMS 在内，垃圾收集的目标范围要么是整个新生代 (Minor GC), 要么就是整个老年代 (Major GC),再要么就是整个Java 堆 (Full GC)。而 G1 跳出 了这个樊笼，它可以面向堆内存任何部分来组成回收集(Collection Set,一般简称 CSet) 进 行回收，衡量标准不再是它属于哪个分代，而是哪块内存中存放的垃圾数量最多，回收收 益最大，这就是G1 收集器的 Mixed GC 模式。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们 18664393530@aliyun.com 处理，核实后本网站将在24小时内删除侵权内容。