JVM垃圾回收机制及算法（四）

垃圾回收机制及算法

垃圾回收基础知识

什么是GC

​ Java 与 C++等语言最大的技术区别：自动化的垃圾回收机制（GC）

​ 栈：栈中的生命周期是跟随线程，所以一般不需要关注

​ 堆：堆中的对象是垃圾回收的重点

​ 方法区/元空间：这一块也会发生垃圾回收，不过这块的效率比较低，一般不是我们关注的重点

垃圾回收算法

复制算法（Copying）

​ 将可用内存按容量划分大小相等的两块，每次只使用其中的一次。当这一块的内存用完了，就将还存活的对象复制到另一块上面，然后把已经使用过一次的内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要按顺序分配内存即可，实现简单，运行高效。只是这种算法的代价是将内存缩小为原来的一半。

​ 但是要注意：内存移动是必须实打实的移动（复制），所以对应的引用（直接指针）需要调整。

​ 复制回收算法适合于新生代，因为大部分对象朝生夕死，那么复制过去的对象比较少，效率自然高。

Appel 式回收

​ 一种更加优化的复制回收分代策略：分配一块较大的Eden区和两块较小的Survivor空间（也可以叫做 From 或者 To，也可以叫做 Survivor1 和 Survivor2）

​ 专门研究表明，新生代中的对象98%是“朝生夕死”的，所以并不需要按照1：1的比例老划分内存空间，而是将内存分为一块较大的 Eden 区和两块较小的 Survivor 区，每次使用 Eden 和其中一块 Survivor 1。当回收时，将Eden 和 Survivor 中还存活着的对象一次性的复制到另外一块 Survivor 区上，最后清理掉 Eden 和 刚才用过的 Survivor 区。

​ HotSpot 虚拟机默认 Eden 和 Survivor 的大小比例是 8：1，也就是每次新生代中可用内存空间为整个新生代容量的 90% （80%+10%），只有 10%的内存会被“浪费”。当然，98%的对象可回收只是一般场景下的数据，我们没有办法保证每次回收都只有不多于 10%的对象存活，当 Survivor 空间不够用时，需要依赖其他内存（这里指老年代）进行分配担保（Handle Promotion）

标记-清除算法（Mark-Sweep）

​ 算法分为“标记”和“清除”两个阶段：首先扫描所有对象标记出需要回收的对象，在标记完成后扫描回收所有被标记的对象，所以需要扫描两遍。

​ 回收效率略低，如果大部分对象是朝生夕死，那么回收效率降低，因为需要大量标记对象和回收对象，对比复制回收效率要低。

​ 它的主要问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾回收动作。

​ 回收的时候如果需要回收的对象越多，需要做的标记和清除的工作越多，所以标记清除算法适用于老年代

标记-整理算法（Mark-Compact）

​ 首先标记出所有需要回收的对象，在标记完成后，后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。标记整理算法虽然没有内存碎片，但是效率偏低。

​ 我们看到标记整理与标记清除算法的区别主要在于对象的移动。对象移动不单单会加重系统负担，同时需要全程暂停用户线程才能进行，同时所有引用对象的地方都需要更新（直接指针需要调整）。

​ 所以看到，老年代采用的标记整理算法与标记清除算法，各有优点，各有缺点。

JVM中常见的垃圾回收器

在新生代中，每次垃圾回收时都发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成回收。

而老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须使用“标记—清理”或者“标记—整理”算法来进行回收。

新生代

回收器	回收对象和算法	回收器类型
Serial	新生代，复制算法	单线程(串行)
Parallel Scavenge	新生代，复制算法	并行的多线程回收器
ParNew	新生代，复制算法	并行的多线程收集器

对应的老年代

回收器	回收对象和算法	回收器类型
Serial Old	老年代，标记整理算法	单线程(串行)
Parallel Old	老年代，标记整理算法	并行的多线程回收器
CMS	老年代，标记清除算法	并发的多线程回收器
G1*	跨新生代和老年代；标记整理 + 化整为零	并发的多线程回收器

Serial / Serial Old（了解）

​ JVM 刚诞生就只有这种，最古老的，单线程，独占式，成熟，适合单 CPU，一般用在客户端模式下。

​ 这种垃圾回收器只适合几十兆到一两百兆的堆空间进行垃圾回收（可以控制停顿时间再 100ms 左右），但是对于超过这个大小的内存回收速度很慢，所以对于现在来说这个垃圾回收器已经是一个鸡肋。

参数设置

-XX:+UseSerialGC 新生代和老年代都用串行收集器

Stop The World （STW）

​ 单线程进行垃圾回收时，必须暂停所有的工作线程，直到它回收结束。这个暂停称之为“Stop The World”，但是这种STW带来了恶劣的用户体验，例如：应用每运行一个小时就需要暂停响应5分钟。

Parallel Scavenger （ParallelGC） / Parallel Old

​ 为了提高回收效率，从 JDK1.3 开始，JVM 使用了多线程的垃圾回收机制，关注吞吐量的垃圾收集器，高吞吐量则可以高效率地利用 CPU 时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。

​ 所谓吞吐量就是 CPU 用于运行用户代码的时间与 CPU 总消耗时间的比值，即吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间），虚拟机总共运行了 100 分钟，其中垃圾收集花掉 1 分钟，那吞吐量就是 99%。

该垃圾回收器适合回收堆空间上百兆~几个 G。

参数设置

开启参数

JDK1.8 默认就是以下组合

-XX:+UseParallelGC 新生代使用 Parallel Scavenge，老年代使用 Parallel Old

收集器提供了两个参数用于精确控制吞吐量，分别控制的停顿时间的-XX:MaxGCPauseMillis 参数以及直接设置吞吐量大小的-XX:GCTimeRatio 参数。

https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html

-XX:MaxGCPauseMillis

不过大家不要异想天开地认为如果把这个参数的值设置得更小一点就能使得系统的垃圾收集速度变得更快，垃圾收集停顿时间缩短是以牺牲吞吐量和新生代空间为代价换取的:系统把新生代调得小一些，收集 300MB 新生代肯定比收集 500MB 快，但这也直接导致垃圾收集发生得更频繁，原来 10 秒收集一次、每次停顿 100 毫秒，现在变成 5 秒收集一次、 每次停顿 70 毫秒。停顿时间的确在下降，但吞吐量也降下来了。

-XX:GCTimeRatio

-XX:GCTimeRatio 参数的值则应当是一个大于 0 小于 100 的整数，也就是垃圾收集时间占总时间的比率，相当于吞吐量的倒数。

例如：把此参数设置为 19, 那允许的最大垃圾收集时占用总时间的 5% (即 1/(1+19))， 默认值为 99，即允许最大 1% (即 1/(1+99))的垃圾收集时间由于与吞吐量关系密切，ParallelScavenge 是“吞吐量优先垃圾回收器”。

-XX:+UseAdaptiveSizePolicy

-XX:+UseAdaptiveSizePolicy （默认开启）。这是一个开关参数， 当这个参数被激活之后，就不需要人工指定新生代的大小(-Xmn)、Eden 与 Survivor 区的比例(-XX:SurvivorRatio)、 晋升老年代对象大小(-XX:PretenureSizeThreshold)等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量。

Concurrent Mark Sweep（CMS）

​ 收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的 Java 应用集中在互联网站或者 B/S 系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMS 收集器就非常符合这类应用的需求。

​ 从名字（包含“Mark Sweep”）上就可以看出，CMS 收集器是基于“标记—清除”算法实现的，它的运作过程相对于前面几种收集器来说更复杂一些，整个过程分为 4 个步骤，包括：

1. 初始标记-短暂，仅仅只是标记一下 GC Roots 能直接关联到的对象，速度很快。
2. 并发标记-和用户的应用程序同时进行，进行 GC Roots 追踪的过程，标记从 GC Roots 开始关联的所有对象开始遍历整个可达分析的对象。这个时间比较长，所以采用并发处理（垃圾回收器线程和用户线程同时工作）
3. 重新标记-短暂，为了修正并发标记期间因用户程序继续运转而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段长一一些，但远比并发标记的时间短。
4. 并发清除：

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

-XX:+UseConcMarkSweepGC ，表示新生代使用 ParNew，老年代的用 CMS

CMS 问题

**CPU 敏感：**CMS 对处理器资源敏感，毕竟采用了并发的收集、当处理核心数不足 4 个时，CMS 对用户的影响较大。

**浮动垃圾：**由于 CMS 并发清理阶段用户线程还在运行着，伴随程序运行自然就还会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS 无法在当次收集中处理掉它们，只好留待下一次 GC 时再清理掉。这一部分垃圾就称为“浮动垃圾”。由于浮动垃圾的存在，因此需要预留出一部分内存，意味着 CMS 收集不能像其它收集器那样等待老年代快满的时候再回收。

在 1.6 的版本中老年代空间使用率阈值(92%)

如果预留的内存不够存放浮动垃圾，就会出现 Concurrent Mode Failure，这时虚拟机将临时启用 Serial Old 来替代 CMS。

**会产生内存碎片：**标记-清除 算法会导致产生不连续的内存碎片

​ 总体来说，CMS 是 JVM 推出了第一款并发垃圾收集器，所以还是非常有代表性。

​ 但是最大的问题是 CMS 采用了标记清除算法，所以会有内存碎片，当碎片较多时，给大对象的分配带来很大的麻烦，为了解决这个问题，CMS 提供一个参数：-XX:+UseCMSCompactAtFullCollection，一般是开启的，如果分配不了大对象，就进行内存碎片的整理过程。

​ 这个地方一般会使用 Serial Old ，因为 Serial Old 是一个单线程，所以如果内存空间很大、且对象较多时,CMS 发生这样情况会很卡。

CMS 总结

​ CMS 问题比较多，所以现在没有一个版本默认是 CMS，只能手工指定。但是它毕竟是第一个并发垃圾回收器，对于了解并发垃圾回收具有一定意义，所以我们必须了解

​ 为什么 CMS 采用标记-清除，在实现并发的垃圾回收时，如果采用标记整理算法，那么还涉及到对象的移动（对象的移动必定涉及到引用的变化，这个需要暂停业务线程来处理栈信息，这样使得并发收集的暂停时间更长），所以使用简单的标记-清除算法才可以降低 CMS 的 STW 的时间。

该垃圾回收器适合回收堆空间几个 G~ 20G 左右。

在 JDK1.8 中，配置参数：

Garbage First（G1）

设计思想

​ 随着 JVM 中内存的增大，STW 的时间成为 JVM 急迫解决的问题，但是如果按照传统的分代模型，总跳不出 STW 时间不可预测这点。

​ 为了实现 STW 的时间可预测，首先要有一个思想上的改变。G1 将堆内存“化整为零”，将堆内存划分成多个大小相等独立区域（Region），每一个 Region 都可以根据需要，扮演新生代的 Eden 空间、Survivor 空间，或者老年代空间。回收器能够对扮演不同角色的 Region 采用不同的策略去处理，这样无论是新创建的对象还是已经存活了一段时间、熬过多次收集的旧对象都能获取很好的收集效果。

Region

​ Region 可能是 Eden,也有可能是 Survivor,也有可能是 Old,另外 Region 中还有一类特殊的 Humongous 区域，专门用来存储大对象。 G1 认为只要大小超过了一个 Region 容量一半的对象即可判定为大对象。每个 Region 的大小可以通过参数-XX:G1HeapRegionSize 设定，取值范围为 1MB~32MB,且应为 2 的 N 次 幂。而对于那些超过了整个 Region 容量的超级大对象，将会被存放在 N 个连续的 Humongous Region 之中，G1 的进行回收大多数情况下都把 Humongous Region 作为老年代的一部分来进行看待。

参数设置

开启参数

-XX:+UseG1GC

分区大小

-XX:+G1HeapRegionSize

一般建议逐渐增大该值，随着 size 增加，垃圾的存活时间更长，GC 间隔更长，但每次 GC 的时间也会更长。

最大 GC 暂停时间

MaxGCPauseMillis

运行过程

G1 的运作过程大致可划分为以下四个步骤:

初始标记（Initial Marking）

​ 仅仅只是标记一下 GC Roots 能直接关联到的对象，并且修改 TAMS 指针的值，让下一阶段用户线程并发运行时，能正确地在可用的 Region 中分配新对象。这个阶段需要停顿线程，但耗时很短，而且是借用进行 Minor GC 的时候同步完成的，所以 G1 收集器在这个阶段实际并没有额外的停顿。

TAMS 是什么？

​ 要达到 GC 与用户线程并发运行，必须要解决回收过程中新对象的分配，所以 G1 为每一个 Region 区域设计了两个名为 TAMS（Top at Mark Start）的指针，从 Region 区域划出一部分空间用于记录并发回收过程中的新对象。这样的对象认为它们是存活的，不纳入垃圾回收范围。

并发标记（Concurrent Marking）

​ 从 GC Root 开始对堆中对象进行可达性分析，递归扫描整个堆里的对象图，找出要回收的对象，这阶段耗时较长，但可与用户程序并发执行。当对象图扫描完成以后 ， 并 发时有引用变动的对象， 这些对象会漏标（ 三色标记可以解决这个问题 ） ， 漏标的对象会被一个叫做 SATB(snapshot-at-the-beginning)算法来解决（这个下节课会细讲）

最终标记（FinalMarking）

​ 对用户线程做另一个短暂的暂停，用于处理并发阶段结后仍遗留下来的最后那少量的 SATB 记录(漏标对象)。

筛选回收（Live Data Counting and Evacuation）

​ 负责更新 Region 的统计数据，对各个 Region 的回收价值和成本进行排序，根据用户所期望的停顿时间来制定回收计划，可以自由选择任意多个 Region 构成回收集集，然后把决定回收的那一部分 Region 的存活对象复制到空的 Region 中，再清理掉整个旧 Region 的全部空间。这里的操作涉及存活对象的移动，是必须暂停用户线程，由多条收集器线程并行完成的。

特点

并行与并发：G1 能充分利用多 CPU、多核环境下的硬件优势，使用多个 CPU（CPU 或者 CPU 核心）来缩短 Stop-The-World 停顿的时间，部分其他收集器原本需要停顿 Java 线程执行的 GC 动作，G1 收集器仍然可以通过并发的方式让 Java 程序继续执行。

分代收集： 与其他收集器一样，分代概念在 G1 中依然得以保留。虽然 G1 可以不需要其他收集器配合就能独立管理整个 GC 堆，但它能够采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次 GC 的旧对象以获取更好的收集效果。

空间整合： 与 CMS 的“标记—清理”算法不同，G1 从整体来看是基于“标记—整理”算法实现的收集器，从局部（两个 Region 之间）上来看是基于“复制”算法实现的，但无论如何，这两种算法都意味着 G1 运作期间不会产生内存空间碎片，收集后能提供规整的可用内存。这种特性有利于程序长时间运行，分配大对象时不会因为无法找到连续内存空间而提前触发下一次 GC。

追求停顿事时间：

-XX:MaxGCPauseMillis 指定目标的最大停顿时间，G1 尝试调整新生代和老年代的比例，堆大小，晋升年龄来达到这个目标时间。

开启G1

该垃圾回收器适合回收堆空间上百 G。一般在 G1 和 CMS 中间选择的话平衡点在 6~8G，只有内存比较大 G1 才能发挥优势。

在这里插入图片描述

垃圾回收整理

收集器	收集对象和算法	收集器类型	说明	适用场景
Serial	新生代，复制算法	单线程		简单高效；适合内存不大的情况
ParNew	新生代，复制算法	并行的多线程收集器	ParNew 垃圾收集器是Serial 收集器的多线程版本	搭配CMS垃圾回收器的首选
Parallel Scavenge（吞吐量优先收集器）	新生代，复制算法	并行的多线程收集器	类似 ParNew，更加关注吞吐量，达到一个可控制的吞吐量；	本身是 Server 级别多 CPU 机器上的默认 GC 方式，主要适合后台运算不需要太多交互的任务

收集器	收集对象和算法	收集器类型	说明	适用场景
Serial Old	老年代，标记整理算法	单线程		Client 模式下虚拟机使用
Parallel Old	老年代，标记整理算法	并行的多线程收集器	Parallel Scavenge 收集器的老年代版本，为了配合 Parallel Scavenge 的面向吞吐量的特性而开发的对应组合	在注重吞吐量以及 CPU 资源敏感的场合采用
CMS	老年代，标记清除算法	并行的多线程收集器	尽可能的缩短垃圾收集时用户线程停止时间；缺点在于： 1.内存碎片 2.需要更多 cpu 资源 3.浮动垃圾问题，需要更大的堆空间	重视服务的响应速度、系统停顿时间和用户体验的互联网网站或者 B/S 系统。互联网后端目前 cms 是主流的垃圾回收器
G!	跨新生代和老年代；标记整理 + 化整为零	并行的多线程收集器	JDK1.7 才正式引入，采用分区回收的思维，基本不牺牲吞吐量的前提下完成低停顿的内存回收；可预测的停顿是其最大的优势；	面向服务端应用的垃圾回收器，目标为取代 CMS

并行：垃圾收集的多线程的同时

并发：垃圾收集的多线程和应用的多线程同时进行。

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

垃圾收集时间= 垃圾回收频率 * 单次垃圾回收时间