转载

6.HotSpot中的GC收集器简介

概述

整理归纳HotSpot中的GC收集器相关性能，算法使用，GC过程和相互搭配。需要先明确一个观点：GC收集器根本上来说没有绝对的优劣，我们只能根据具体场景选择最适合的GC组合，而不是选择一个完美的GC组合。

介绍之前，先需要了解两个名词概念：

并行：多条GC线程并行工作，此时用户线程仍处于停顿状态
并发：用户线程与垃圾收集线程同时执行（并行或交替执行）

6.HotSpot中的GC收集器简介

新生代GC

Serial收集器

单线程

单线程有两个方面含义： 一方面 ，serial收集器只使用一个CPU或一条收集线程进行GC； 另一方面 ，serial进行GC时，需要暂停其他所有的工作线程直到垃圾回收结束（Stop The World）

一方面，Serial收集器只是用一条GC线程去执行收集任务；另一方面，Serial收集器进行收集时，必须暂停其他所有的工作线程(Stop The World)，直到收集结束。

新生代采用复制算法；老年代采用标记-整理算法
Client模式下默认新生代收集器，能与CMS搭配使用

6.HotSpot中的GC收集器简介

ParNew收集器

多线程GC，采用多线程进行收集工作
Server模式下的虚拟机中首选的新生代收集器，能与CMS搭配使用
除多线程GC外，其余参数包括Serial收集器可用的所有控制参数、Stop The World、收集算法、对象分配规则、回收策略都与Serial完全一样

6.HotSpot中的GC收集器简介

Parallel Scavenge收集器

多线程并行GC
新生代采用复制算法；老年代采用标记-清除算法
关注吞吐量
GC自适应调节策略

吞吐量 = 运行用户代码时间 / (运行用户代码时间 + 垃圾收集时间)

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

停顿时间短适合需要和用户交互多的程序；高吞吐量可以高效利用CPU使用率，适合在后台运算而不需要太多交互的任务。

Parallel Scavenge收集器提供两个参数用于控制吞吐量：

-XX:MaxGCPauseMillis ：最大垃圾收集停顿时间。值与新生代空间和吞吐量成反比。

-XX:GCTimeRatio：吞吐量大小。值可以理解为正常运行时间相对垃圾收集时间的倍数，即正常运行时间/垃圾回收时间，默认值为99，即允许最大1%(1/1+99)的垃圾收集时间。

GC自适应调节策略：

Parallel Scavenge收集器还有一个参数-XX:+UseAdaptiveSizePolicy设置当前系统是否使用自适性系统参数调节，当开关打开时，系统不需要手动设置新生代大小、Eden和Survivor比例、晋升老年代对象年龄。

老年代GC

Serial Old收集器

Serial收集器老年代版本
单线程
标记-整理算法
JDK1.5 以及以前的版本中与 Parallel Scavenge 收集器搭配使用
CMS收集器备用预案，在CMS发生“Concurrent Mode Failure”时使用

6.HotSpot中的GC收集器简介

Parallel Old收集器

Parallel Scavenge收集器老年代版本，与Parallel Scavenge收集器搭配，构成“名副其实”的“吞吐量优先”收集器
多线程并行GC
标记-整理算法

![Parallel Scavenge/Parallel Old

收集器运行过程.png]( https://upload-images.jianshu...

CMS(Concurrent Mark Sweep)收集器

HotSpot第一款真正意义上的并发收集器。第一次实现了GC线程和工作线程(基本上)同时工作

收集过程

初始标记
并发标记
重复标记
并发清除

初始标记

只标记GC Roots能直接关联到的对象，需要Stop The World(STW)。

并发标记

进行GC Roots引用链追踪，标记所有有关联的对象。这时GC线程能和用户线程同时工作(用书上的形容是：真正的实现了你边丢垃圾，你妈妈边打扫卫生)。

重复标记

修正并发标记时，发生引用关系变化的那部分对象的引用，需要Stop The World。

并发清除

使用并发-清除算法对垃圾对象进行清除。

并发重置

CMS清除内部状态，为下次GC做准备

评价

并发收集、低停顿

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

并发-清除算法

不足

与用户线程争夺CPU资源

虽然并发标记和并发清除时，不会导致用户线程停顿，但由于占用一部分线程资源而导致应用程序速度变慢。CMS默认启动的回收线程是(CPU数量 + 3) / 4

无法处理浮动垃圾

CMS收集器进行到并发清除阶段时，由于并发执行，系统仍然会产生一些垃圾，这些垃圾产生在标记之后，所以需要等待下次GC再清除他们，这些垃圾叫做“浮动垃圾”。正因如此，CMS收集器对老年代需要预留一部分空间提供并发收集时的程序运作使用。

CMS通过设置参数（-XX:CMSInitiatingOccupancyFraction）用来表示老年代使用多少空间时，激活CMS。设置这个参数需要有两方面的考量：一方面，当参数值设置过低，触发CMS的GC次数会变多，降低性能；另一方面，当参数值设置过高，剩余空间不足以存储产生的浮动垃圾，系统会报“Concurrent Mode Failure”，系统将启动预备方案：使用Serial Old收集器进行老年代的垃圾收集，这样导致耗时更多，影响性能。

并发-清除算法产生大量空间碎片

并发-清除算法将产生大量空间碎片，当大对象进入内存时，会由于没有足够的连续内存空间分配而提前触发Full GC。

为此设计者提供了两个参数。 -XX:+UseCMSCompactAtFullCollection 开关参数控制CMS收集器在需要进行Full GC时，是否开启内存碎片整理过程（默认是开启的）。 -XX:CMSFullGCsBeforeCompaction 设置执行多少次不压缩内存空间的Full GC后，进行一次带压缩的Full GC（ 默认为0，即每次进入Full GC都要进行碎片整理 ）。

6.HotSpot中的GC收集器简介

G1收集器（暂时根据《深入理解Java虚拟机》第二版总结的，之后看了第三版再更新）

代替Parallel Scavenge和Parallel Old组合收集器，成为JDK1.9服务端模式下默认垃圾收集器。设计初衷是建立起“停顿时间模型”的收集器，即支持指定在一个长度为M毫秒的时间片段内，消耗在GC上的时间不超过N毫秒这样的目标。

简述

可预测的停顿
分代收集
并发
标记-清除，两个Region之间局部表现为标记-复制
Region不分代导致记忆集和其他内存消耗较大。

可预测的停顿：G1支持使用者设置在M时间中停顿N秒。G1在后台维护一个列表用于记录每个Region里面的垃圾回收的价值（回收获得的空间大小和回收所需时间），根据用户设置的时间，制定回收计划，优先回收价值大的区域（Garbage-First的由来）。

收集思想(Mixed GC模式)

之前的垃圾收集器的垃圾收集对象为整个新生代(Minor GC)、整个老年代(Major GC)或整个Java堆(Full GC)。而G1面向 堆内存的任何部分来组成回收集 进行垃圾回收，衡量标准不再是内存属于哪个年代，而是 哪块内存中存放的垃圾数量最多，回收收益最大 。

堆内存布局(Region、Humongous)

为了实现这一收集目标，G1的堆内存布局开创了 基于Region 的堆内存布局。

G1虽仍然遵循分代收集，但是不同于之前的收集器将年轻代、年老代和元空间按照固定大小以及固定数量进行区域划分，而是将连续的Java堆划分为大小相等的若干区域——Region，每个区域根据需要可以是任何年代的对象，各个年代没有物理连续只有逻辑上的连续。收集器就可以根据扮演不同年代的Region采用不同的回收策略。

除此之外，增加了一个区域—— Humongous区域 ，用于存储巨型对象，如果一个对象占用空间超过Region容量的一般，G1则认为这是一个巨型对象(Region取值范围为1MB~32MB，应为2的N次幂，通过-XX:G1HeapRegionSize设定)。如果一个Region装不下一个巨型对象，则会寻找连续的Humongous分区来存储，有时为找到连续的H分区，有时会触发Full GC 。H区域的出现避免了短期存在的巨型对象对GC造成负面影响。G1大多数行为把H区域当做老年代看待。

6.HotSpot中的GC收集器简介

可预测的停顿时间模型

有了新的垃圾收集思想和堆内存布局，“可预测的停顿时间模型”得以实现：

追求应付应用的内存分配速率而不是追求一次把Java堆收集干净
每次收集时将Region作为回收最小单元，即 每次回收的内存空间都是Region的整数倍 ，避免了全区域收集，因此 时间可控 。
收集具体思路是让G1收集器去跟踪各个Region里面的垃圾堆积的“价值”大小，即回收得到的空间以及回收所需时间的经验值，然后在后台维护一个优先级列表，每次根据用户设定的收集停顿时间(默认200毫秒) 优先处理回收价值收益最大的那些Region 。