6.HotSpot中的GC收集器简介

目录

• 概述
• 新生代GC
• 老年代GC
• java789默认GC搭配
• 垃圾收集器相关参数总结

概述

整理概括HotSpot中的GC收集器相关性能，算法使用，GC过程和相互搭配。须要先明确一个观点：GC收集器根本上来讲没有绝对的优劣，咱们只能根据具体场景选择最适合的GC组合，而不是选择一个完美的GC组合。
介绍以前，先须要了解两个名词概念：

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

新生代GC

Serial收集器

• 单线程

单线程有两个方面含义： 一方面，serial收集器只使用一个CPU或一条收集线程进行GC； 另外一方面，serial进行GC时，须要暂停其余全部的工做线程直到垃圾回收结束（Stop The World）
一方面，Serial收集器只是用一条GC线程去执行收集任务；另外一方面，Serial收集器进行收集时，必须暂停其余全部的工做线程(Stop The World)，直到收集结束。

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

ParNew收集器

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

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”时使用

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都要进行碎片整理）。

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区域当作老年代看待。

可预测的停顿时间模型

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

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

收集过程

• 初始标记
• 并发标记
• 最终标记
• 筛选回收

初始标记

只标记GC Roots能直接关联到的对象，修改TAMS指针值，让下个阶段能正确的在可用Region中分配对象。须要停顿线程，但借用Minor GC的时候同步完成，没有额外停顿。

并发标记

从GC Roots进行可达性遍历，对整个Java堆的对象图进行扫描，找出回收对象。这个阶段能够和用户线程并发执行。还要从新处理SATB记录下的在并发时引用有变更的对象。

最终标记

处理并发阶段后遗留下来的少许的SATB 记录，须要短暂暂停。

SATB（Snapshot At The Beginning）：简单地说就是初始标记阶段和并发标记阶段标记为活的的对象就是活的。而后并发标记阶段新增或者引用从新执行的对象也认为是活的。其余的就是死的

筛选回收

更新Region统计数据，对各Region回收价值和成本进行排序，根据用户指望停顿时间来指定回收计划。回收过程将决定回收的那一部分Region的存活对象复制到空的Region中，而后清理掉旧的Region的所有空间。须要停顿用户线程。

由回收过程能够看出G1并不是纯粹追求低延迟，而是在延迟可控的状况下得到尽量高的吞吐量。

java789默认GC搭配

jdk1.7 Parallel Scavenge(新生代)+Parallel Old(老年代)
jdk1.8 Parallel Scavenge(新生代)+Parallel Old(老年代)
jdk1.9 G1

垃圾收集器参数总结