一、垃圾回收简介

1、什么是垃圾回收（GC）

• 标记阶段：通过一系列算法标准来判断一个对象是否为垃圾，标记阶段在执行时会暂停用户线程，俗称 Stop The World，简称 STW。

• 清理阶段：通过垃圾收集器执行回收。

2、标记算法

• 引用计数器算法

• 可达性分析算法

引用计数法

• 无法回收循环引用。若两个或多个对象互相引用（如双向链表、父对象持有子对象且子对象反向引用父对象），它们的引用计数永远不会归零，即使这些对象已不可达，也无法被回收。

• 空间开销：因为需要单独的字段存储计数器，增加了存储空间的开销。

• 性能开销：每次引用赋值或销毁时都需要增减计数，尤其在多线程环境下需保证原子性，增加了额外的同步开销。

注意引用计数法只是没有在 Java 中使用，不代表这个算法没有实用价值。引用计数算法是很多语言的资源回收选择，例如因人工智能而更加火热的 Python，它更是同时支持引用计数和垃圾收集机制。

Python 如何解决循环引用？

• 手动解除：很好理解，就是在合适的时机，解除引用关系。

• 使用弱引用 weakref， weakref 是 Python 提供的标准库，旨在解决循环引用。

可达性分析算法

• Class 对象：由系统类加载器(system class loader)加载的对象，这些类是不能够被回收的，例如基本数据类型对应的 Class 对象、一些常驻的异常对象（如：NullPointerException、OutOfMemoryError） 、系统类加载器。他们可以以静态字段的方式保存持有其它对象。我们需要注意的一点就是，通过用户自定义的类加载器加载的类，除非相应的 java.lang.Class 实例以其它的某种（或多种）方式成为 roots，否则它们并不是 roots。

• 静态变量引用的对象：即类中static修的成员变量。

• 常量引用的对象：即类中final static修饰的成员变量。

• 虚拟机栈中引用的对象：例如当前正在运行的方法中的局部变量、参数等

• 本地方法栈中 JNI 引用的对象：即 Native 方法引用的对象

• 同步锁持有的对象：所有被同步锁 synchronized 持有的对象

• JMXBean、JVMTI 中注册的回调、本地代码缓存等

• 在可达性分析算法中，只有能够被根对象集合直接或者间接连接的对象才是存活对象。

• 如果要使用可达性分析算法来判断内存是否可回收，那么分析工作必须在一个能保障一致性的快照中进行。这点不满足的话分析结果的准确性就无法保证。这点也是导致 GC 进行时必须 Stop The World 的一个重要原因。即使是号称（几乎）不会发生停顿的 CMS 收集器中，枚举 GC Roots 时也是必须要停顿的。

Stop The World

为什么会发生 STW？

• Serial GC：完全 STW

• Parallel GC：多线程回收但仍有 STW

• CMS：初始标记和重新标记阶段 STW

• G1：年轻代回收和混合回收有 STW

• ZGC/Shenandoah：通过读屏障等技术极大减少STW时间

3、垃圾回收算法

4、四种对象引用

• 强引用（StrongReference)：无法被回收。最传统的 “引用” 的定义，是指在程序代码之中普遍存在的引用赋值，即类似 object obj = new object ( ) 这种引用关系。无论任何情况下，只要强引用关系还存在，垃圾收集器就永远不会回收掉被引用的对象。

• 软引用（SoftReference）：内存不足即回收。在系统将要发生内存溢出之前，将会把这些对象列入回收范围之中进行第二次回收。如果这次回收后还没有足够的内存，才会抛出内存溢出异常。

• 弱引用（WeakReference) ：发生垃圾收集（full gc）即回收。被弱引用关联的对象只能生存到下一次垃圾收集之前。当垃圾收集器工作时，无论内存空间是否足够，都会回收掉被弱引用关联的对象。

• 虛引用（PhantomReference)：不影响回收，对象回收跟踪。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虛引用来获得一个对象的实例。为一个对象设置虛引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。

强引用

软引用

弱引用

虚引用

5、finalize机制

• 在 finalize() 时可能会导致对象复活。

• finalize()方法的执行时间是没有保障的，它完全由GC线程决定，极端情况下，若不发生GC，则 finalize()方法将没有执行机会。

• 一个糟糕的 finalize() 会严重影响 GC 的性能。

1. 如果对象 objA 到 GC Roots 没有引用链,则进行第一次标记。

2. 进行筛选，判断此对象是否有必要执行 finalize()方法。
1. 如果对象 objA 没有重写 finalize() 方法，或者 finalize() 方法已经被虚拟机调用过，则虚拟机视为"没有必要执行"，objA 被判定为不可触及，加入被回收的集合。
2. 如果对象 objA 重写了 finalize()方法，且还未执行过，那么 objA 会被插入到 F-Queue队列中，由一个虚拟机自动创建的、低优先级的 Finalizer 线程触发其 finalize() 方法。
3. finalize() 方法是对象逃脱死亡的最后机会。稍后 GC 会对 F-Queue 队列中的对象进行第二次标记。如果 objA 在 finalize() 方法中重新赋值给一个静态变量或可达引用，那么在第二次标记时，objA 会被移出"即将回收"集合。
4. 之后，如果对象会再次出现没有引用存在的情况。在这个情况下，finalize()方法不会被再次调用，对象会直接变成不可触及的状态，也就是说一个对象的 finalize()方法只会被调用一次。

6、GC的安全点和安全区域

OopMap

• 栈帧和寄存器内的引用。在即时编译中，在特定的位置记录下栈里和寄存器里哪些位置是引用。在 JVM中，一个线程为一个栈，一个栈由多个栈桢组成，一个栈桢对应一个方法，一个栈帧可能有多个 OopMap。

• 对象内的引用。比如一旦类加载动作完成的时候， HotSpot 就会把对象内什么偏移量上是什么类型的数据计算出来。注：把存储单元的实际地址与其所在段的段地址之间的距离称为段内偏移，也称为有效地址或偏移量，因此，实际地址 = 所在段的起始地址 + 偏移量。

安全点

• 发生 STW 的时候用户线程要跑到 Safe Point 挂起。当 GC 回收需要停止用户线程的时候，用户线程不能随意挂起。JVM 设置某个全局中断标志位，各个线程不断轮询这个标志位，发现需要挂起时，自己跑到最近的安全点，更新完 OopMap 才能挂起。

• 只有在 Safe Point 才会生成（或更新）对应的 OopMap。

• 所有的非计数循环的末尾（防止循环体的执行时间太长，一直进入不了 Safe Point）。

• 所有调用方法的入口。

• 所有方法返回之前。

• 抛出异常的位置。

• Safe Point 的数量不能太少，太少会导致进入 Safe Point 的前置时间过长，以至于垃圾回收线程等待的时间太长。

• Safe Point 的数量也不能太多，太多意味着将会频繁生成（或更新）OopMap ，会有性能损耗。

• 抢占式中断(Preemptive Suspension)。JVM 会中断所有线程，然后依次检查每个线程中断的位置是否为 Safe Point，如果不是则恢复用户线程，让它执行至 Safe Point 再阻塞。目前很少 JVM 采用这种方案，

• 主动式中断(Voluntary Suspension)。大部分 JVM 实现都是采用主动式中断，需要阻塞用户线程的时候，首先做一个标志，用户线程会主动轮询这个标志位，如果标志位处于就绪状态，就自行中断。

安全区域

1. 进入 Safe Region：线程执行到 Safe Region 时，首先标记自己已经进入 Safe Region。这个标识告诉 JVM 该线程当前处于安全状态。

2. GC 发生时的处理：如果在安全区域内发生 GC，JVM 会忽略那些已经标识为处于 Safe Region 状态的线程，不会强制它们暂停。

3. 离开 Safe Region：当线程将要离开 Safe Region 时，线程需要检查 JVM 是否已经完成 GC Roots 枚举。如果尚未完成，则需要一直等待，直到 GC Roots 枚举完成。

1. 线程休眠（Sleep）：当线程调用 Thread.sleep() 方法时，它会进入安全区域，直到休眠结束。

2. 线程阻塞（Blocked）：当线程因为等待 I/O 操作或锁而阻塞时，它也会进入安全区域。

3. JNI 调用：在执行本地方法（JNI 调用）时，Java线 程可能无法及时响应 JVM 的中断请求，这时也需要安全区域机制。

OopMap、Safe Point 和 Safe Region 的关联和区别。

• HotSpot 使用 OopMap 把引用类型的指针记录下来，提高 GC Roots 枚举的效率。

• 为了减少更新 OopMap 的开销，引入了 Safe Point。GC 发生 STW 时，线程需要跑到距离自己最近的安全点，更新完 OopMap 才能挂起。

• 处于 Sleep 或者 Blocked 状态的线程无法跑到安全点，需要引入 Safe Region。GC 的时候，不会去管处于安全区域的线程，线程离开安全区域的时候，如果处于 STW 则需要等待直至恢复。

• 安全点主要针对正在执行的线程，而安全区域针对那些无法立即响应中断的非活动线程。安全区域可以看作是安全点的扩展，它扩大了 GC 可以安全执行的范围。

7、吞吐量和暂停时间

• 吞吐量：运行用户代码的时间占总运行时间的比例，计算公式为 吞吐量 = 用户线程运行时间 / （用户线程运行时间 + 垃圾收集时间），高吞吐量可能对每次 STW 时长没有要求，只要求在单位时间内 STW 总时长最短。

• 暂停时间：执行垃圾回收时用户线程被暂停的时间，即每次 STW 的时长。

• 高吞吐量意味着大量时间都是应用程序线程在做 “生产性” 工作，吞吐量越高，程序单位时间内完成的任务越多，但是用户体验可能卡顿明显。例如上面的单位时间内发生了两次停顿，每次200ms，虽然大部分时间都是用户线程在工作，但是每次停顿时间过长，从用户体验的角度来看可能就是界面一卡一卡的。

• 低暂停时间意味着每次停顿的时间少，暂停时间越短，程序越流畅不卡顿，用户体验更好，但是单位时间内完成的任务可能不多。例如上面单位时间内发生了五次停顿，每次 100ms，暂停的总时间更多，导致用户线程的工作总时间减少，但是因为每次停顿时间短，从用户体验的角度来看可能就是界面流畅，但是程序完成的任务不多。

• 如果选择以吞吐量优先，那么必然需要降低内存回收的执行频率，但是这样会导致 GC 需要更长的暂停时间来执行内存回收。

• 如果选择以低延迟优先，那么为了降低每次执行内存回收时的暂停时间，也只能频繁地执行内存回收，但这又引起了年轻代内存的缩减和导致程序吞吐量的下降。

8、串行、并行和并发垃圾回收器

• 串行垃圾回收器：单线程进行垃圾回收，此时用户线程仍然处于等待状态。

• 并行垃圾回收器：多线程程并行执行垃圾回收，但此时用户线程仍然处于等待状态。

• 并发垃圾回收器：垃圾回收线程和用户线程同时执行（但不一定是并行的，可能会交替执行），此时垃圾回收线程可以是单线程或多线程。

二、垃圾回收器

1、垃圾回收器介绍

• 串行回收器：Serial、Serial Old

• 并行回收器：ParNew、Parallel Scavenge、Parallel Old

• 并发回收器：CMS、G1

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

• 老年代收集器：Serial Old、Parallel Old、CMS

• 整堆收集器：G1

1. 两个收集器间有连线，表明它们可以搭配使用：Serial GC + Serial Old、Serial + CMS、ParNew + Serial Old、ParNew + CMS、Parallel Scavenge + Serial Old、Parallel Scavenge + Parallel Old、G1。

2. 其中 Serial Old 作为 CMS 出现 “Concurrent Mode Failure" 失败的后备预案。

3. (红色虚线)由于维护和兼容性测试的成本，在 JDK 8 时將 Serial + CMS、ParNew + Serial Old这两个组合声明为废弃(JEP 173)，并在 JDK 9 中完全取消了这些组合的支持(JEP214)，即移除。

4. (绿色虚线)JDK 14中，弃用 Parallel Scavenge 和 Serial Old GC 组合(JEP 366 )

5. (蓝色虚线)JDK 14中，删除 CMS 垃圾回收器 (JEP 363)

• java8 默认使用：Parallel Scavenge GC + PS MarkSweep（Serial Old GC）

• java9 默认使用：G1

• client模式、单CPU等硬件较差：Serial GC + Serial Old GC

• 追求高吞吐量：ParNew GC + CMS GC（Serial Old GC备用）

• java 14 之后只剩下 Serial GC + Serial Old GC、Parallel Scavenge GC + Parallel Old GC 和 G1 这三种组合。

2、Serial GC 和 Serial Old GC

• 与新生代的 Parallel Scavenge 配合使用。

• 作为老年代 CMS 收集器的后备垃圾收集方案。

• 运行在 Client 模式下的虚拟机（客户端）。

3、ParNew GC

• ParNew 收集器运行在多CPU的环境下，由于可以充分利用多CPU、多核心等物理硬件资源优势，可以更快速地完成垃圾收集，提升程序的吞吐量。

• 但是在单个CPU的环境下，ParNew收集器不比Serial 收集器更高效。虽然Serial收集器是基于串行回收，但是由于CPU不需要频繁地做任务切换，因此可以有效避免多线程交互过程中产生的一些额外开销。

4、Parallel Scavenge GC + Parallel Old GC

• 和 ParNew 收集器不同，Parallel Scavenge 收集器的目标则是达到一个可控制的吞吐量（Throughput），也被称为吞吐量优先的垃圾收集器。高吞吐量则可以高效率地利用 CPU 时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。因此，常见在服务器环境中使用。例如，那些执行批量处理、订单处理、工资支付、科学计算的应用程序。

• 自适应调节策略也是 Parallel Scavenge 与 ParNew 一个重要区别。

• Parallel Scavenge 收集器有时候会使用 PS 前缀，即命名为 PS Scavenge，本身包含了老年代收集器，被命名为 PS MarkSweep。但由于 PS MarkSweep 与 Serial Old 实现非常接近，基本是使用同一份代码，因此官方的许多资料都直接以 Serial Old 代替 PS MarkSweep 进行讲解。

• 在 JDK 8 及更高版本，如果只设置 -XX:+UseParallelGC，JVM 会 自动启用-XX:+UseParallelOldGC，即老年代也会使用并行收集。而在 JDK 7 或更早版本，-XX:+UseParallelGC 不会自动启用老年代并行，需要显式设置 -XX:+UseParallelOldGC。可以通过 jcmd 或 jinfo 查看是否启用 -XX:+UseParallelOldGC 。

5、CMS GC

CMS GC的回收过程

• 初始标记阶段（Initial-Mark）：仅标记 GC Roots 直接可达的对象（如栈帧中的局部变量、静态变量等）以及新生代晋升到老年代的对象。Java7 单线程，Java8 多线程，STW，速度非常快。

• 并发标记阶段（Concurrent Mark）：从第一阶段扫描出来的初始标记对象开始遍历全部老年代对象，在执行阶段由于新生代晋升到老年代等原因，导致部分老年代引用关系发生变化，把受影响的老年代的对象所在的 Card 标记为 Dirty，和用户线程并发执行，耗时较长。

• 并发预清理阶段（Concurrent-Preclean）：1）扫描 Dirty Card，并标记被 Dirty 对象直接或间接引用的对象，然后清除 Card 标识。2）处理新生代对老年代的引用（如 Eden 区新分配的对象引用了老年代对象）。并发预清理阶段的目的是为了让重新标记阶段的 STW 尽可能短，和用户线程并发执行，可通过CMSPrecleaningEnabled关闭。



如上所示，3 的引用发生了变化，将 6 标记为存活

• 可中断预清理（Concurrent-Abortable-Preclean）：有一些老年代对象的存活是因为被新生代引用，为了尽快确定这些老年代对象可以尽量减少新生代的对象数量，可以先进行一次 Minor GC。可中断预清理阶段的目的是为了让重新标记阶段的 STW 尽可能短，和用户线程并发执行，可设置参数不执行。

• 重新标记阶段（Remark）：遍历整个堆标记老年代存活对象，包括遍历新生代对象、GC Roots、老年代的 Dirty Card 对象并重新标记。STW，比初始标记耗时稍微长一点，远比并发标记时间短。

• 并发清除阶段（Concurrent-Sweep）：清理未被标记的垃圾对象（采用标记-清除算法，不整理内存），和用户线程并发执行。

• 并发重置阶段（Concurrent-Reset）：重置 CMS 内部数据结构，为下次回收做准备。

CMS GC的问题

既然 Mark Sweep 会造成内存碎片，那么为什么不把算法换成 Mark Compact 呢？原因是：当并发清除的时候，用 Compact 整理内存的话，原来的用户线程使用的内存还怎么用呢？要保证用户线程能继续执行，前提的它运行的资源不受影响嘛。Mark-Compact 更适合 “Stop the World” 这种场景下使用。

• 老年代空间不足：老年代剩余连续空间不足以容纳从新生代晋升的对象。

• 内存碎片问题：虽然老年代总空间足够，但由于CMS使用标记-清除算法产生内存碎片，无法找到足够的连续空间存放晋升的大对象。

1. CMS 触发太晚。由于在垃圾收集阶段用户线程没有中断，应用线程仍然会把对象放入老年代，所以 CMS 收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，而是当堆内存使用率达到某一阈值时，便开始进行回收。如果 CMS 回收触发太晚，预留的内存无法满足程序需要，就会报错。

2. 内存碎片问题。老年代内存碎片过多，无法分配大对象

3. 对象分配速率超过 CMS 回收速率。有可能是年轻代晋升到老年代的速度过快，也有可能是 CMS 的回收速率太低。

6、G1 GC

• 并行 + 并发。
• 并行性：G1 在回收期间，可以有多个 GC 线程同时工作，有效利用多核计算能力。此时用户线程 STW。
• 并发性：G1 拥有与应用程序交替执行的能力，部分工作可以和应用程序同时执行，因此，一般来说，不会在整个回收阶段发生完全阻塞应用程序的情况

• 全新的分代概念。从分代上看，G1 依然属于分代型垃圾回收器。但不要求各代都是连续逻辑空间，将堆空间分为多个 Region（默认约 2048 个），每个 Region 都可能是 Eden、Survivor、Old、Humongous 区其中的一种。Region 的角色可以互换。例如 Eden 区被清空之后变成空白区域，加入空闲列表，后面可能会变成 Old 区用来存放老年代对象。

• 空间整合，避免内存碎片。G1 将内存划分为一个个的 Region，内存的回收是以 Region 作为基本单位的。Region之间是复制算法，但整体上实际可看作是标记-压缩（Mark-Compact）算法，两种算法都可以避免内存碎片。这种特性有利于程序长时间运行，分配大对象时不会因为无法找到连续内存空间而提前触发下一次 GC。尤其是当 Java 堆非常大的时候，G1 的优势更加明显。

• 可预测的停顿时间模型（软实时 soft real-time）。这是 G1 相对于 CMS 的另一大优势，G1 除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为 M 毫秒的时间片段内，消耗在垃圾收集上的时间不得超过 N 毫秒。G1 跟踪各个 Region 里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的 Region。保证了 G1 收集器在有限的时间内可以获取尽可能高的收集效率。

Region

RSet（Remember Set）

• 每个 Region 都会对应一个 Rset，Rset 记录了其他 Region 对当前 Region 的引用。。例如上面的 Region1、Region2、Region3 分别对应一个 Rset， Region2 的 Rset 中记录了 Region1 和 Region3 对当前 Region 的引用信息。

• Rset 需要保存的引用关系：
• Old Region → Young Region（老年代引用年轻代）。年轻代的 Region 的 RSet 只保存来自老年代的引用。这是因为年轻代的回收是针对所有年轻代 Region 的，没必要画蛇添足。所以说年轻代 Region 的 RSet 有可能是空的。
• Old Region → Old Region（老年代引用老年代）。老年代的 Region 的 RSet 也只会保存老年代对它的引用。这是因为老年代回收之前，会先对年轻代进行回收。这时，Eden 区变空了，而在回收过程中会扫描 Survivor 分区，所以也没必要保存来自年轻代的引用。

1. 在 Minor GC 的时候，只需要选定年轻代的 RSet 作为 GC ROOTs，这些 RSet 记录了 Old -> Young 的跨代引用，避免了扫描整个老年代。

2. 在 Mixed GC 的时候，老年代中记录了 Old -> Old 的RSet，Young -> Old 的引用从 Survivor 区获取（老年代回收之前，会先对年轻代进行回收，存活的对象放在 Survivor 区），这样也不用扫描全部老年代。

CSet（Collection Set）

1. 根据 Region 的垃圾多少来判断与预估回收价值（指回收的垃圾与回收的 STW 时间的一个预估值），将一个或者多个 Region 放到 CSet。

2. 对 Cset 的 Region 进行扫描分析。

3. 在满足回收条件后，最后将这些 Region 中的存活对象压缩并复制到新的 Region 中，清空原来的 Region。

• fully-young generational mode模式：该模式下 CSet 将只包含 Young Region 和 Survivor Region。G1 将调整 Young 的 Region 的数量来匹配软实时的目标。

• partially-young mode模式：该模式会选择所有的 Young Region、Survivor Region 和一部分的 Old Region。Old Region 的选择将依据在 Marking cycle phase 中对存活对象的计数。G1 选择存活对象最少的 Region 进行回收。

IHOP

SATB（Snapshot At the Begging）

1. 最开始所有的标记位都是 0，如果发现对象是可达的就会置为 1，一步步下去就会呈现一个类似树状的结果。

2. 等标记的步骤完成后，会将未被标记的对象统一清理，再次把所有的标记位设置成 0 方便下次清理。

• 白色：对象没有被标记到，标记阶段结束后，会被当做垃圾回收掉。

• 灰色：对象被标记了，但是但该对象下的属性没有全被标记完。GC 需要从此对象中去寻找垃圾。

• 黑色：对象被标记了，且该对象下的属性也全部都被标记过了。这是程序所需要的对象。

1. 在 GC 标记开始的时候，所有的对象均为白色。

2. 从 GC Roots 触发，在将所有的 GC Roots 直接引用的对象标记为灰色集合。

3. 从灰色集合中取出对象，将其引用的白色对象标记为灰色，自身标记为黑色

4. 按照此步骤 3，直到没有灰色对象。

5. 标记结束后，白色的对象为 GC Roots 不可达，进行垃圾回收。

1. 对象 A 被标记为了黑色，此时它所引用的两个对象 B、C 都在被标记的灰色阶段。

2. 此时用户线程把 B->D 之间的的引用关系删除，并且在 A->D 之间建立引用。

3. 此时 B 对象依然未扫描结束，而 A 对象又已经被扫描过了，不会继续接着往下扫描了。因此 D 对象虽然是被引用的对象，但是因为仍然被当做垃圾回收掉。

• 有至少一个黑色对象在自己被标记之后指向了白色对象。

• 所有的灰色对象在自己引用扫描完成之前删除了对白色对象的引用。

1. 在开始标记的时候生成一个快照图标记存活对象。

2. 在一个引用断开后（例如上面的 B 和 D 之间的引用），要将被断开的引用（D）推到 GC 的堆栈里，保证白色对象还能被 GC 线程扫描到(在write barrier 里把所有旧的引用所指向的对象都变成非白的)。

3. 配合 Rset，去扫描哪些 Region 引用到当前的白色对象，若没有引用到当前对象，则回收。

• 增量更新算法关注的是引用的增加（ A->C 的引用）
• 优点：避免浮动垃圾。
• 缺点：需要再次扫描被重新标记为灰色对象的所有引用，效率低。

• 原始快照算法关注的是引用的删除（ B->C的引用）
• 优点：效率非常高，无需扫描整个引用链
• 缺点：这个白色对象有可能并没有黑色对象去引用它，但是它还是被变灰了，就会导致它和它的引用，本来应该被垃圾回收掉，但是此次 GC 存活了下来，就是所谓的浮动垃圾。其实这样是比较可以忍受的，只是让它多存活了一次 GC 而已，浪费一点点空间，但是会比增量更新更省时间。

G1 GC的回收过程

1. 扫描根。根是指 static 变量指向的对象，正在执行的方法调用链条上的局部变量等。根引用连同 RSet 记录的外部引用作为扫描存活对象的入口。

2. 更新 Rset。处理 dirty card queue中的 card，更新 RSet。此阶段完成后，RSet 可以准确的反映老年代对所在的内存分段中对象的引用。

3. 处理 RSet。识别被老年代对象指向的 Eden 中的的对象，这些被指向的 Eden 中的对象被认为是存活的对象。

4. 复制对象。此阶段，对象树被遍历，Eden 区内存段中存活的对象会被复制到 Survivor 区中空的内存分段，Survivor 区内存段中存活的对象如果年龄未达阈值，年龄会加1，达到阈值会被复制到 Old 区中空的内存分段。如果 Survivor 空间不够，Eden 区中部分数据会直接晋升到老年代空间。

5. 处理引用。处理 Soft，Weak，Phantom，Final，JNI Weak 等引用。最终 Eden 空间的数据为空，GC 停止工作，而目标内存中的对象都是连续存储的，没有碎片，所以复制过程可以达到内存整理的效果，减少碎片。

1. 初始标记阶段（Initial marking phase）：扫描 GC Roots 直接可达对象。这个阶段是 STW，并且会触发一次 Young GC。

2. 根扫描区域（Root region scanning phase）：扫描 Survivor Region 直接可达的老年代对象，并标记被引用的对象，这个阶段是并发进行的，要在下一个 Young GC 开始之前结束。

3. 并发标记阶段（Concurrent marking phase）：标记整个堆的存活对象。该过程是并发进行的，但是可以被 Young GC 所打断。
1. 在并发标记阶段，若发现区域对象中的所有对象都是垃圾，那这个区域会被立即回收。
2. 并发标记过程中，会计算每个区域的对象活性(区域中存活对象的比例)。
3. 并发阶段产生的新的引用（或者引用的更新）会被 SATB 的 write barrier 记录下来。

4. 重新标记阶段（Remark phase）：也叫 final marking phase。该阶段只需要扫描 SATB，处理在并发阶段产生的新的存活对象的引用，相当于修正上一次的标记结果。这个阶段是 STW 。

5. 独占清理阶段（Cleanup phase）：计算各个区域的存活对象和 GC 回收比例，把完全没有存活对象的 Region 直接放到空闲列表中，并进行排序，识别可以混合回收的区域。该阶段还会重置RSet。
1. 该阶段不会真的清除，而是为下阶段做铺垫。
2. 该阶段在计算 Region 中存活对象的时候是 STW 的，而在重置 RSet 的时候是可以并发进行的。

6. 并发清理阶段：识别并清理完全空闲的区域。

• 一个周期里的单次 STW 的 Mixed GC 和 Young GC 是类似的，唯一区别就是在混合收集过程中会包含一部分老年分区。也就是说 Miixed GC 的 CSet 会把一部分 Old Region 放到 Eden Region 和 Survivor Region 的后面一起进行回收。

• G1 GC 会进行多次 Mixed GC，直到收集到足够数量的老年代区域。

• Mixed GC 结束，本次 GC 周期就算完成了。GC 将恢复到 Young GC，开启下一轮 GC 周期。

• 加大内存。

• 提高 CPU 性能，加快 GC 回收速度，使对象增加速度赶不上回收速度。

• 降低进行 Mixed GC 触发的阈值，让 Mixed GC 提早发生（默认45%）。

G1 GC的适用场景

• 面向服务端应用，针对具有大内存、多处理器的机器。(在普通大小的堆里表现并不惊喜)

• 最主要的应用是需要低 GC 延迟，并具有大堆的应用程序提供解决方案；如：在堆大小约 6GB 或更大时，可预测的暂停时间可以低于 0.5 秒；（G1 通过每次只清理一部分而不是全部的 Region 的增量式清理来保证每次 GC 停顿时间不会过长）。

• 用来替换掉 JDK1.5 中的CMS收集器； 在下面的情况时，使用 G1 可能比 CMS 好：
• 超过 50％ 的 Java 堆被活动数据占用
• 对象分配频率或年代提升频率变化很大
• GC停顿时间过长（长于0.5至1秒）

• HotSpot 垃圾收集器里，除了 G1 以外，其他的垃圾收集器使用内置的 JVM 线程执行 GC 的多线程操作，而 G1 GC 可以采用应用线程承担后台运行的 GC 工作，即当 JVM 的 GC 线程处理速度慢时，系统会调用应用程序线程帮助加速垃圾回收过程。

7、ZGC

 

 

• JDK 14 之前，ZGC 仅 Linux 才支持。

• 尽管许多使用 ZGC 的用户都使用类 Linux 的环境，但在 Windows 和 macOS 上，人们也需要 ZGC 进行开发部署和测试。许多桌面应用也可以从 ZGC 中受益。因此，ZGC 特性被移植到了 Windows和 macOS 上。

• 现在 macOS 或 Windows上也能使用 ZGC了，示例如下： XX:+UnlockExperimentalVMOptions -XX:+UseZGC

8、垃圾回收器设置

三、垃圾回收相关问题

1、什么时候会发生 Full GC

1. 调用 System.gc() 。但调用后不一定立即发生 Full GC，由 JVM 控制 GC 的时机(可通过 -XX:+DisableExplicitGC 禁用 )。

2. 老年代的可用空间不足。

3. 方法区空间不足时。

4. 空间担保失败。通过 Minor GC 后进入老年代的平均大小大于老年代的可用内存。

5. GC 晋升失败（Promotion Failed）：由 Eden 区、From Survior 区向 To Survior 区复制时，对象大小大于 To Survior 区可用内存，则把该对象转存到老年代，且老年代的可用内存小于该对象大小时。

6. Concurrent Mode Failure。如果老年代使用了 CMS 垃圾回收器，因为 CMS 垃圾回收器的垃圾回收线程和用户线程是并发执行的，在 CMS GC 的过程中，如果新生代 Survivor 空间放不下，需要放入老年代，而老年代也放不下，或者用户直接把对象放入老年代放不下，就会报 Concurrent Mode Failure。

7. 执行 jmap -histo:live 或者 jmap -dump:live。

2、空间分配担保机制

• 如果大于，那么此次 Minor GC 是安全的。

• 如果小于，则 JVM 查看 -XX:HandlePromotionFailture 是否允许担保失败。
• 如果 HandlePromotionFailture=true ，那么会继续检查老年代最大可用连续空间是否大于历次晋升到老年代对象的平均大小。
• 如果大于，则尝试进行一次 Minor GC，但此次 Minor GC 仍然是有风险的。
• 如果小于，则改为进行一次 Full GC。
• 如果 HandlePromotionFailture=false ，则改为进行一次 Full GC。

为什么需要空间担保机制？

3、动态年龄判断

• Survivor 区大小 = 100MB

• 年龄分布：年龄1 = 30MB，年龄2 = 30MB，年龄3 = 20MB

• 年龄1(30MB) < 50MB(一半)

• 年龄1 + 年龄2(60MB) > 50MB

• 大对象直接进入老年代。那多大的对象是大对象？这个阈值通过 -XX:PretenureSizeThreshold 参数来配置。

• 年龄大于阈值，进入老年代。这个阈值通过 -XX:MaxTenuringThreshold 来配置，默认是 15。

• 动态年龄判断涉及到一个值，就是 survivor 区域的一半，其实也不一定是一半，可以通过 -XX:TargetSurvivorRatio 来配置。

4、内存溢出和内存泄漏

• 内存溢出：申请内存的时候没有足够的内存可用。

• 内存泄漏：对象不再被使用，但是垃圾收集器又不能回收这些对象。

1. 静态集合类。如 HashMap、LinkedList 等等。如果这些容器为静态的，那么它们的生命周期与 JVM 程序一致，则容器中的对象在程序结束之前将不能被释放，从而造成内存泄漏。简单而言，长生命周期的对象持有短生命周期对象的引用，尽管短生命周期的对象不再使用，但是因为长生命周期对象持有它的引用而导致不能被回收。

2. 单例模式。和静态集合导致内存泄露的原因类似，因为单例的静态特性，它的生命周期和 JVM 的生命周期一样长，所以如果单例对象如果持有外部对象的引用，那么这个外部对象也不会被回收，那么就会造成内存泄漏。

3. 内部类持有外部类。如果一个外部类的实例对象的方法返回了一个内部类的实例对象。这个内部类对象被长期引用了，即使那个外部类实例对象不再被使用，但由于内部类持有外部类的实例对象，这个外部类对象将不会被垃圾回收，这也会造成内存泄漏。

4. 各种连接，如数据库连接、网络连接和 IO 连接等。在对数据库进行操作的过程中，首先需要建立与数据库的连接，当不再使用时，需要调用 close 方法来释放与数据库的连接。只有连接被关闭后，垃圾回收器才会回收对应的对象。否则，如果在访问数据库的过程中，对 Connection、Statement 或 ResultSet 不显性地关闭，将会造成大量的对象无法被回收，从而引起内存泄漏。

5. 变量不合理的作用域。一般而言，一个变量的定义的作用范围大于其使用范围，很有可能会造成内存泄漏。另一方面，如果没有及时地把对象设置为 null，很有可能导致内存泄漏的发生。
• 如上面这个伪代码，通过 readFromNet 方法把接受的消息保存在变量 msg 中，然后调用 saveDB 方法把msg的内容保存到数据库中，此时 msg 已经就没用了，由于 msg 的生命周期与对象的生命周期相同，此时 msg 还不能回收，因此造成了内存泄漏。实际上这个 msg 变量可以放在 receiveMsg 方法内部，当方法使用完，那么 msg 的生命周期也就结束，此时就可以回收了。
• 还有一种方法，在使用完 msg 后，把 msg 设置为 null，这样垃圾回收器也会回收 msg 的内存空间。

6. 改变哈希值。当一个对象被存储进 HashSet 集合中以后，就不能修改这个对象中的那些参与计算哈希值的字段了。否则，对象修改后的哈希值与最初存储进 HashSet 集合中时的哈希值就不同了，在这种情况下，即使在 contains 方法使用该对象的当前引用作为的参数去HashSet集合中检索对象，也将返回找不到对象的结果，这也会导致无法从HashSet集合中单独删除当前对象，造成内存泄漏。这也是 String 为什么被设置成了不可变类型，我们可以放心地把 String 存入 HashSet，或者把String 当做 HashMap 的 key 值。当我们想把自己定义的类保存到散列表的时候，需要保证对象的 hashCode 不可变。
示例

7. 缓存泄漏。内存泄漏的另一个常见来源是缓存，一旦把对象引用放入到缓存中，就很容易遗忘。比如：之前项目在一次上线的时候，应用启动奇慢直到夯死，就是因为代码中会加载一个表中的数据到缓存（内存）中，测试环境只有几百条数据，但是生产环境有几百万的数据。对于这个问题，可以使用 WeakHashMap 代替缓存。此种 Map 的特点是，当除了自身有对 key 的引用外，此 key 没有其他引用那么此 map 会自动丢弃此值。
示例
程序运行结果：
上面代码和图示主要演示 WeakHashMap 如何自动释放缓存对象，当 init 函数执行完成后，局部变量字符串引用 weakd1，weakd2 都会消失，此时只有静态 map 中保存中对字符串对象的引用，可以看到，调用 gc 之后，HashMap 的没有被回收，而 WeakHashMap 里面的缓存被回收了。

8. 监听器和其他回调。内存泄漏常见来源还有监听器和其他回调，如果客户端在你实现的 API 中注册回调，却没有显示的取消，那么就会积聚。需要确保回调立即被当作垃圾回收的最佳方法是只保存它的弱引用，例如将他们保存成为 WeakHashMap 中的键。
示例
上面这段代码的主要问题在 pop()，这里只做了指针的移动，但是引用未手动置空，所以是不会释放内存的。可以改成这样。