垃圾收集器

深入理解Java虚拟机：JVM高级特性与最佳实践（第3版）

垃圾收集器

HotSpot虚拟机的垃圾收集器

JDK 7 Update 4之后、JDK 11正式发布之前，OracleJDK中的HotSpot虚拟机所包含的全部可用的垃圾收集器。

两个收集器之间存在连线，就说明它们可以搭配使用。

新生代垃圾收集器：Serial、ParNew、Parallel Scavenge

老年代垃圾收集器：CMS、Serial Old（MSC）、Parallel Old

新生代、老年代共同垃圾收集器：G1

Stop The World：指的是GC事件发生过程中，会产生应用程序的停顿。停顿产生时整个应用程序线程都会被暂停，没有任何响应, 有点像卡死的感觉，这个停顿称为Stop The World，简称STW。

Serial收集器

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

Serial收集器和Serial Old收集器工作过程：

Serial收集器收集新生代垃圾，采用复制算法，暂停所有用户线程（Stop The World）

Serial Old收集器收集老年代，采用标记—整理算法，暂停所有用户线程。

Serial收集器与其他收集器的单线程相比简单高效，对于内存资源受限的环境，它是所有收集器里额外内存消耗最小的：对于单内核货核心数较少的环境来说，Serial收集器没有线程交互的开心，专心做垃圾收集可以获得最高的单线程收集效率。

Serial收集器对于运行在客户端模式下的虚拟机来说是一个很好的选择。

ParNew收集器

ParNew收集器实质上是Serial收集器的多线程版本。除了同时使用多条线程进行垃圾收集之外，其余的行为包括Serial收集器的所有控制参数、收集算法、Stop The World、对象分配规则、回收策略等都与Serial收集器完全一致。

ParNew收集器和Serial Old收集器工作过程：

ParNew收集器收集新生代垃圾，采用复制算法，暂停所有用户线程（Stop The World）

Serial Old收集器收集老年代，采用标记—整理算法，暂停所有用户线程。

ParNew收集器是运行在服务端模式下的HotSpot虚拟机（尤其在JDK之前的遗留系统中）首选新生代垃圾收集器，他是除了Serial收集器外，目前只有它能与CMS收集器配合工作。

Parallel Scavenge收集器

Parallel Scavenge收集器是一款新生代收集器，它是基于标记—复制算法实现的收集器，能够并行收集的多线程收集器。

CMS等收集器关注点是尽可能的缩短垃圾收集时用户线程的停顿时间，Parallel Scavenge收集器的目标是达到一个可控制的吞吐量。

虚拟机完成某个任务，用户代码加上垃圾收集总共消费100分钟，其中垃圾收集花掉1分钟，吞吐量就是99%。

参数

• -XX:MaxGCPauseMillis：控制最大垃圾收集停顿时间，大于0的毫秒数。收集器尽量保证垃圾收集的时间不超过设置值，并不是越小越好。以空间换时间，以频繁的回收来换取每次收集的时间变少。
• -XX:GCTimeRatio：吞吐量的大小。大于0小于100的整数，垃圾收集时间占总时间的比率
• -XX:+UseAdaptiveSizePolicy：自动开关，当这个参数激活，不需要人工指定新生代、Eden与Survivor区的比例（-XX:SurvivorRatio）、晋升老年代对象大小（-XX:PretenureSizeThreshold）等细节参数，虚拟机会根据当前系统运行情况，动态调整这些参数以提供最合适的停顿时间。

Serial Old收集器

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

Serial Old收集器工作过程：

Paralle Old收集器

Paralle Old收集器是Parallel Scavenge收集器的老年代版本，支持多线程并发收集，基于标记—整理算法实现。JDK1.6时开始提供。

Paralle Old收集器工作过程：

CMS收集器

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。基于标记—清楚算法实现，它的运作过程分为四个步骤：

1. 初始标记（CMS initial mark）

   初始标记仅仅只是标记一个GC Roots能直接关联到的对象，速度很快。

2. 并发标记（CMS concurrent mark）

   并发标记阶段就是从GC Roots的直接关联对象开始遍历整个对象图的过程，这个过程耗时较长但是不需要停顿用户线程，可以与垃圾收集线程一起并发运行。

3. 重新标记（CMS remark）

   重新标记阶段是为了修正并发标记阶段期间，因用户线程继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间通常比初始标记阶段稍微长一些，但也远比并发标记阶段的时间短。

4. 并发清除（CMS concurrent sweep）

   清理删除掉标记阶段判断的已经死亡的对象，由于不需要移动存活对象，这个阶段也是与用户线程同时并发的。

初始标记和重新标记需要停止用户线程（Stop The World）。

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

CMS收集器工作过程：

Garbage First收集器

Garbage First（简称G1）收集器是一款面向服务端应用的垃圾收集器。JDK9发布之日，G1宣告取代Parallel Scavenge加Parallel Old组合，成为服务端模式下的默认垃圾收集器，而CMS被声明为不推荐使用的收集器。

G1收集器面向堆内存任何部分来组成回收集进行回收，衡量标准不再是它属于哪个分代，而是哪块内存中存放的垃圾数量最多，回收利益最大（G1收集器的Mixed GC模式）。

G1也仍遵循分代收集理论设计的，但其堆内存的布局与其他收集器有非常明显的差异：G1不再坚持固定大小及固定数量的分代区域划分，而是把连续的Java堆划分为多个大小相等的独立区域（Region），每一个独立区域（Region）都可以根据需要，扮演新生代的Eden空间、Survivor空间，或者老年代空间。G1收集器能够对扮演不同角色的独立区域（Region）采用不同的策略去处理，这样无论是新创建的对象还是已经存活一段时间、熬过多次垃圾收集的旧对象都能获取很好的收集效果。G1收集器虽然仍保留新生代和老年代的概念，但新生代和老年代不再是固定的，它们都是一系列区域（不需要连续）的动态集合。

独立区域（Region）中有一类特殊的Humongous区域，专门用来存储大对象。G1收集器认为只要对象大小超过了一个Region容量一半的对象即可判定为大对象。Region容量可以通过参数：-XX:G1HeapRegionSize设定，取值范围为1MB~32MB，应为2的N次幂。

G1收集器Region分区示意图：

G1收集器工作过程：

1. 初始标记（Initial Marking）：仅仅标记一下GC Roots能直接关联到的对象，并且修改TAMS指针的值，让下一阶段用户线程并发运行时，能正确的在可用的Region中分配新对象。这个阶段需要停顿线程，但耗时很短，而且是借用进行Minor GC的时候同步完成的，所以G1收集器在这个阶段实际并没有额外的停顿。
2. 并发标记（Concurrent Marking）：从GC Roots开始对堆中对象进行可达性分析，递归扫描整个堆里的对象图，找出要回收的对象，这个阶段耗时较长，但可与用户线程并发执行。当对象图扫描完成以后，还要重新处理SATB记录下的在并发时有引用变动的对象。
3. 最终标记（Final Marking）：对用户线程做另一个短暂的暂停，用于处理并发阶段结束后仍遗留下来的最后那少量的SATB记录。
4. 筛选回收（Live Data Counting And Evacuation）：负责更新Region的统计数据，对各个Region的回收价值和成本进行排序，根据用户所期望的停顿时间来制定回收计划，可以自由选择任意多个Region构成回收集，然后把决定回收的那一部分Region的存活对象复制到空的Region中，再清理的整个旧Region的全部空间。这里的操作涉及存活对象的移动，是必须暂停用户线程，由多条收集器线程并行完成的。

除并发标记外，其余阶段要完全暂停用户线程。