课堂笔记：JVM（三）GC算法和收集器

三、GC算法和收集器

上节课程回顾：

面试题：YoungGC和FullGC有什么区别？

• YoungGC:发生在新生代的GC，非常频繁，因为一般来讲新对象是朝生夕灭。
• FullGC：发生在老年代，回收时间慢，理论上慢10倍。

---

##GC过程演示

public class GCTest {
    public static void main(String[] args) {
        byte[] allocation1 = new byte[28000 * 1024];
    }
}

随后我们给JVM添加打印GC的参数

-XX:+PrintGCDetails

Heap
 PSYoungGen      total 57344K, used 32915K [0x0000000780800000, 0x0000000784800000, 0x00000007c0000000)
  eden space 49152K, 66% used [0x0000000780800000,0x0000000782824f30,0x0000000783800000)
  from space 8192K, 0% used [0x0000000784000000,0x0000000784000000,0x0000000784800000)
  to   space 8192K, 0% used [0x0000000783800000,0x0000000783800000,0x0000000784000000)
 ParOldGen       total 131072K, used 0K [0x0000000701800000, 0x0000000709800000, 0x0000000780800000)
  object space 131072K, 0% used [0x0000000701800000,0x0000000701800000,0x0000000709800000)
 Metaspace       used 3237K, capacity 4496K, committed 4864K, reserved 1056768K
  class space    used 350K, capacity 388K, committed 512K, reserved 1048576K

Process finished with exit code 0

此时可以看到新生代、老年代、元空间的信息，这些内存大小由于没有自己指定，所以是JVM自动分配的。

接下来我们修改代码，增加新的数组进去，看看回收情况。

public class GCTest {
    public static void main(String[] args) {
        byte[] allocation1 = new byte[28000 * 1024];
        byte[] allocation2 = new byte[900 * 1024];
        byte[] allocation3 = new byte[20000 * 1024];
    }
}

[GC (Allocation Failure) [PSYoungGen: 32832K->1772K(57344K)] 32832K->29780K(188416K), 0.0191782 secs] [Times: user=0.00 sys=0.02, real=0.03 secs] 
Heap
 PSYoungGen      total 57344K, used 22263K [0x0000000780800000, 0x0000000787800000, 0x00000007c0000000)
  eden space 49152K, 41% used [0x0000000780800000,0x0000000781c02f98,0x0000000783800000)
  from space 8192K, 21% used [0x0000000783800000,0x00000007839bb030,0x0000000784000000)
  to   space 8192K, 0% used [0x0000000787000000,0x0000000787000000,0x0000000787800000)
 ParOldGen       total 131072K, used 28008K [0x0000000701800000, 0x0000000709800000, 0x0000000780800000)
  object space 131072K, 21% used [0x0000000701800000,0x000000070335a010,0x0000000709800000)
 Metaspace       used 3238K, capacity 4496K, committed 4864K, reserved 1056768K
  class space    used 350K, capacity 388K, committed 512K, reserved 1048576K

Process finished with exit code 0

由此可以看出，比较大的对象是直接放到老年代的。

---

GC算法和收集器

本文参考：周志明《深入理解java虚拟机》第二版

如何判断对象可以被回收

堆中几乎放着所有的对象实例，对堆垃圾回收前的第一步就是要判断哪些对象已经死亡（即不能再被任何途径使用的对象）

引用计数法

给对象添加一个引用计数器，每当有一个地方引用，计数器就加1。当引用失效，计数器就减1。任何时候计数器为0的对象就是不可能再被使用的。

这个方法实现简单，效率高，但是目前主流的虚拟机中没有选择这个算法来管理内存，最主要的原因是它很难解决对象之前相互循环引用的问题。所谓对象之间的相互引用问题，通过下面代码所示：除了对象a和b相互引用着对方之外，这两个对象之间再无任何引用。但是它们因为互相引用对方，导致它们的引用计数器都不为0，于是引用计数器法无法通知GC回收器回收它们。

可达性分析算法

这个算法的基本思想就是通过一系列的称为”GC Roots“的对象作为起点，从这些节点开始向下搜索，节点所走过的路径称为引用链，当一个对象到GC Roots没有任何引用链相连的话，则证明此对象时不可用的。

GC Roots根节点：类加载器、Thread、虚拟机栈的局部变量表、static成员、常量引用、本地方法栈的变量等等

如何判断一个常量是废弃常量

运行时常量池主要回收的是废弃的常量。那么，我们怎么判断一个常量时废弃常量呢？

假如在常量池中存在字符串"abc"，如果当前没有任何String对象引用该字符串常量的话，就说明常量”abc“就是废弃常量，如果这时发生内存回收的话而且有必要的话，”abc“会被系统清理出常量池。

如何判断一个类是无用的类

需要满足以下三个条件：

• 该类所有的实例都已经被回收，也就是 Java 堆中不存在该类的任何实例。
• 加载该类的 ClassLoader 已经被回收。
• 该类对应的 java.lang.Class 对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

虚拟机可以对满足上述3个条件的无用类进行回收，这里仅仅是”可以“，而并不是和对象一样不适用了就必然会被回收。

注意：finalize()方法

​ 如果对象在进行可达性分析之后没有发现与GC Roots相连接的引用链，那它将会被第一次标记并且进行一次筛选，筛选的条件是该对象是否有必要执行finalize()方法。当对象没有覆盖finalize()方法，或者finalize()方法已经被虚拟机调用过，虚拟机都将这两种情况视为“没有必要执行”。注意finalize()方法属于Object，任何类都可以自由的复写该方法。

@Override
    protected void finalize() throws Throwable {
        super.finalize();
    }

​ 如果这个对象被判断为有必要执行finalize()方法，那么这个对象将会被放置在一个叫做F-Query的队列之中，并在稍后有一个虚拟机自动建立的、优先级别较低的Finalizer线程去执行它。

​ finalize()方法是对象逃脱死亡的最后一次机会，稍后GC将对F-Query中的对象进行第二次小规模的标记，如果对象要在finalize()方法中拯救自己-----只要重新与引用链上的任何一个对象建立关联即可，譬如把自己（this关键字）赋值给某个类变量或者对象的成员变量，那在第二次标记时它将被移出即将回收的集合；如果对象还没有逃脱，那它就真的被回收了。

​ 注意，finalize()方法只执行一次，如果再次执行的时候发现该对象依然没有被引用，还是会被回收。

​ 可以考虑线程池，没有被引用的时候仍然需要存活。在finalize()方法中做一个引用即可。

垃圾回收算法

标记-清除算法

它是最基础的收集算法，这个算法分为两个阶段，“标记”和”清除“。首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。它有两个不足的地方：

1. 效率问题，标记和清除两个过程的效率都不高；
2. 空间问题，标记清除后会产生大量不连续的碎片；

复制算法

为了解决效率问题，复制算法出现了。它可以把内存分为大小相同的两块，每次只使用其中的一块。当这一块的内存使用完后，就将还存活的对象复制到另一块区，然后再把使用的空间一次清理掉。这样就使每次的内存回收都是对内存区间的一半进行回收

一般使用在新生代的幸存区。

缺点：只有一半内存可以可以使用。而且，如果复制算法使用在老年代的话，非常伤，会频繁Full GC。

标记-整理算法

根据老年代的特点提出的一种标记算法，标记过程和“标记-清除”算法一样，但是后续步骤不是直接对可回收对象进行回收，而是让所有存活的对象向一段移动，然后直接清理掉边界以外的内存。

注意顺序：先移动、再清理。

分代收集算法

现在的商用虚拟机的垃圾收集器基本都采用"分代收集"算法，这种算法就是根据对象存活周期的不同将内存分为几块。一般将java堆分为新生代和老年代，这样我们就可以根据各个年代的特点选择合适的垃圾收集算法。

在新生代中，每次收集都有大量对象死去，所以可以选择复制算法，只要付出少量对象的复制成本就可以完成每次垃圾收集。而老年代的对象存活几率时比较高的，而且没有额外的空间对它进行分配担保，就必须选择“标记-清除”或者“标记-整理”算法进行垃圾收集

垃圾收集器

java虚拟机规范对垃圾收集器应该如何实现没有任何规定，因为没有所谓最好的垃圾收集器出现，更不会有万金油垃圾收集器，只能是根据具体的应用场景选择合适的垃圾收集器。

Serial收集器

Serial（串行）收集器收集器是最基本、历史最悠久的垃圾收集器了。大家看名字就知道这个收集器是一个单线程收集器了。它的 “单线程” 的意义不仅仅意味着它只会使用一条垃圾收集线程去完成垃圾收集工作，更重要的是它在进行垃圾收集工作的时候必须暂停其他所有的工作线程（ “Stop The World” ），直到它收集结束。

新生代采用复制算法，老年代采用标记-整理算法。

虚拟机的设计者们当然知道Stop The World带来的不良用户体验，所以在后续的垃圾收集器设计中停顿时间在不断缩短（仍然还有停顿，寻找最优秀的垃圾收集器的过程仍然在继续）。

但是Serial收集器有没有优于其他垃圾收集器的地方呢？当然有，它简单而高效（与其他收集器的单线程相比）。Serial收集器由于没有线程交互的开销，自然可以获得很高的单线程收集效率。Serial收集器

对于运行在Client模式下的虚拟机来说是个不错的选择。

ParNew收集器

ParNew收集器其实就是Serial收集器的多线程版本，除了使用多线程进行垃圾收集外，其余行为（控制参数、收集算法、回收策略等等）和Serial收集器完全一样。

新生代采用复制算法，老年代采用标记-整理算法。

它是许多运行在Server模式下的虚拟机的首要选择，除了Serial收集器外，只有它能与CMS收集器（真正意义上的并发收集器，后面会介绍到）配合工作。

Parallel Scavenge收集器(JDK1.8)

Parallel Scavenge 收集器类似于ParNew 收集器。

Parallel Scavenge收集器关注点是吞吐量（高效率的利用CPU）。CMS等垃圾收集器的关注点更多的是用户线程的停顿时间（提高用户体验）。所谓吞吐量就是CPU中用于运行用户代码的时间与CPU总消耗时间的比值。 Parallel Scavenge收集器提供了很多参数供用户找到最合适的停顿时间或最大吞吐量，如果对于收集器运作不太了解的话，手工优化存在的话可以选择把内存管理优化交给虚拟机去完成也是一个不错的选择。

新生代采用复制算法，老年代采用标记-整理算法。

Serial Old收集器

Serial收集器的老年代版本，它同样是一个单线程收集器。它主要有两大用途：一种用途是在JDK1.5以及以前的版本中与Parallel Scavenge收集器搭配使用，另一种用途是作为CMS收集器的后备方案。

Parallel Old收集器

Parallel Scavenge收集器的老年代版本。使用多线程和“标记-整理”算法。在注重吞吐量以及CPU资源的场合，都可以优先考虑 Parallel Scavenge收集器和Parallel Old收集器。

CMS收集器

并行和并发概念补充：

• 并行（Parallel） ：指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态。
• 并发（Concurrent）：指用户线程与垃圾收集线程同时执行（但不一定是并行，可能会交替执行），用户程序在继续运行，而垃圾收集器运行在另一个CPU上。

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。它而非常符合在注重用户体验的应用上使用。

CMS（Concurrent Mark Sweep）收集器是HotSpot虚拟机第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程（基本上）同时工作。

从名字中的Mark Sweep这两个词可以看出，CMS收集器是一种 “标记-清除”算法实现的，它的运作过程相比于前面几种垃圾收集器来说更加复杂一些。整个过程分为四个步骤：

• 初始标记（CMS initial mark）： 暂停所有的其他线程，并记录下直接与root相连的对象，速度很快
• 并发标记（CMS concurrent mark）： 同时开启GC和用户线程，用一个闭包结构去记录可达对象。但在这个阶段结束，这个闭包结构并不能保证包含当前所有的可达对象。因为用户线程可能会不断的更新引用域，所以GC线程无法保证可达性分析的实时性。所以这个算法里会跟踪记录这些发生引用更新的地方。
• 重新标记（CMS remark）： 重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段的时间稍长，远远比并发标记阶段时间短
• 并发清除（CMS concurrent sweep）： 开启用户线程，同时GC线程开始对为标记的区域做清扫。

CMS主要优点：并发收集、低停顿。但是它有下面三个明显的缺点：

• 对CPU资源敏感；
• 无法处理浮动垃圾；
• 它使用的回收算法-“标记-清除”算法会导致收集结束时会有大量空间碎片产生。

G1收集器

G1 (Garbage-First)是一款面向服务器的垃圾收集器,主要针对配备多颗处理器及大容量内存的机器. 以极高概率满足GC停顿时间要求的同时,还具备高吞吐量性能特征.

Region（区域）：G1收集器通过把Java堆分成一个个大小相等的Region，Region是G1回收的最小单元。

CSet（收集集合）：GC过程记录的可被回收的Region的集合。在CSet中存活的数据会在GC过程中被移动到另一个可用分区，CSet中的分区可以来自eden空间、survivor空间、或者老年代。

RSet(Remembered Set 记忆集合)：记录了其他Region中的对象引用本Region中对象的关系，属于points-into结构 (谁引用了我的对象)。作用是不需要扫描整个堆找到谁引用了当前分区中的对象，只需要扫描RSet即可。

在之前的解决跨代收集的方案中采用的是卡表（Card Table）,简单的理解是它记录着老年代哪些区域存在对新生代对象的引用。在G1中由于不再是简单的新生代与老年代，每个Region中都可能被多个其他Region引用，所以用RSet来记录其他Region对当前Region的引用。

RSet示意图如下图：

RSet最简单的结果可以理解成”Hashtable<key,int[]>“结构，其中key对应的就是其他Region，而int[]对应其他Region的卡表。如上图Region2的RSet第一个元素对应Region,int[]中第二个与第四个元素值是1表示”脏“数据，也就是说Region1中的第2块与第4块区域存在对Region的引用，同理也可以得出Region3的第1块与第4块存在对Region2的引用。

在对Region2进行标记的时候，就只通过RSet找到对应哪些内存区域存在对Region2的引用，而不用进行整个堆的扫描。

Humongous regions：用来存放大于标准的Region内存50%的大对象区域，如果有些对象大于整个Region就会去找连续的Region保存，如果没有就会触发GC。

被视为JDK1.7中HotSpot虚拟机的一个重要进化特征。它具备一下特点：

• 并行与并发：G1能充分利用CPU、多核环境下的硬件优势，使用多个CPU（CPU或者CPU核心）来缩短Stop-The-World停顿时间。部分其他收集器原本需要停顿Java线程执行的GC动作，G1收集器仍然可以通过并发的方式让java程序继续执行
• 分代收集：虽然G1可以不需要其他收集器配合就能独立管理整个GC堆，但是还是保留了分代的概念。 空间整合：与CMS的“标记–清理”算法不同，G1从整体来看是基于“标记整理”算法实现的收集器；从局部上来看是基于“复制”算法实现的
• 可预测的停顿：这是G1相对于CMS的另一个大优势，降低停顿时间是G1 和 CMS 共同的关注点，但G1 除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内

G1收集器的运作大致分为以下几个步骤：

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

G1收集器在后台维护了一个优先列表，每次根据允许的收集时间，优先选择回收价值最大的Region(这也就是它的名字Garbage-First的由来)。这种使用Region划分内存空间以及有优先级的区域回收方式，保证了GF收集器在有限时间内可以尽可能高的收集效率（把内存化整为零）。

• G1收集过程

  虽然G1收集器把Java堆化整为零成一个个Region,但是也不会进行所有Region进行收集，G1也分成了两种收集模式，两种模式如下：

  Young GC: CSet就是所有年轻代里面的Region；

  Mixed GC: CSet是所有年轻代里的Region加上在全局并发标记阶段标记出来的收益高的老年代Region；

  Young GC过程：

  阶段1：根扫描，静态和本地对象被扫描；

  阶段2：更新RS，处理dirty card队列更新RS；

  阶段3：处理RS，检测从年轻代指向老年代的对象；

  阶段4：对象拷贝，拷贝存活的对象到survivorl/old区域；

  阶段5：处理引用队列，软引用，弱引用，虚引用处理；

  Mixed GC过程：

  1、全局并发标记（global concurrent marking）

  2、拷贝存活对象（evacuation）

  全局并发标记包括5个步骤：

  1、初始标记（initial mark，STW）：标记了从GCRoot开始直接可达的对象。

  2、根区域扫描（root region scan）：G1 GC 在初始标记的存活区扫描对老年代的引用，并标记被引用的对象。该阶段与应用程序（非 STW）同时运行，并且只有完成该阶段后，才能开始下一次 STW 年轻代垃圾回收。

  3、并发标记（Concurrent Marking）：G1 GC 在整个堆中查找可访问的（存活的）对象。该阶段与应用程序同时运行，可以被 STW 年轻代垃圾回收中断。

  4、重新标记（Remark，STW）：该阶段是 STW 回收，帮助完成标记周期。G1 GC 清空 SATB 缓冲区，跟踪未被访问的存活对象，并执行引用处理。

  5、清除垃圾（Cleanup）：在这个最后阶段，G1 GC 执行统计和 RSet 净化的 STW 操作。在统计期间，G1 GC 会识别完全空闲的区域和可供进行混合垃圾回收的区域。清理阶段在将空白区域重置并返回到空闲列表时为部分并发。
  Full GC

1. 触发条件：

• 晋升失败：G1收集器完成了标记阶段，开始启动混合式垃圾回收，清理老年代的分区，不过，老年代空间在垃圾回收释放出足够内存之前就会被耗尽。垃圾回收日志中，这种情况的现象通常是混合式GC之后紧接着一次Full GC。
• 并发模式失效：G1垃圾收集启动标记周期，但老年代在周期完成之前就被填满，在这种情况下，G1收集器会放弃标记周期
• 疏散失败：进行新生代垃圾收集时，Survivor空间和老年代中没有足够的空间容纳所有的幸存对象。这种情形在GC日志中通常被当成一种特别的新生代：
• 疏散失败: 进行新生代垃圾收集时，Survivor空间和老年代中没有足够的空间容纳所有的幸存对象。这种情形在GC日志中通常被当成一种特别的新生代
• 巨型对象分配失败： 使用G1收集器时，分配非常巨大对象的应用程序可能会遭遇另一种Full GC

注： 发生Full GC时jvm使用的是serial old GC 收集器

注意：在G1收集器中也存在Full GC！只是很少。

怎么选择垃圾收集器？

1. 优先调整堆的大小让服务器自己来选择
2. 如果内存小于100m，使用串行收集器
3. 如果是单核，并且没有停顿时间的要求，串行或JVM自己选择
4. 如果允许停顿时间超过1秒，选择并行或者JVM自己选
5. 如果响应时间最重要，并且不能超过1秒，使用并发收集器

回收，帮助完成标记周期。G1 GC 清空 SATB 缓冲区，跟踪未被访问的存活对象，并执行引用处理。

5、清除垃圾（Cleanup）：在这个最后阶段，G1 GC 执行统计和 RSet 净化的 STW 操作。在统计期间，G1 GC 会识别完全空闲的区域和可供进行混合垃圾回收的区域。清理阶段在将空白区域重置并返回到空闲列表时为部分并发。

怎么选择垃圾收集器？

1. 优先调整堆的大小让服务器自己来选择
2. 如果内存小于100m，使用串行收集器
3. 如果是单核，并且没有停顿时间的要求，串行或JVM自己选择
4. 如果允许停顿时间超过1秒，选择并行或者JVM自己选
5. 如果响应时间最重要，并且不能超过1秒，使用并发收集器

官方推荐G1，性能高。