一、垃圾回收简介

1、什么是垃圾回收

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

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

2、标记算法

引用计数法

• 它需要单独的字段存储计数器，这样的做法增加了存储空间的开销。

• 每次赋值都需要更新计数器，伴随着加法和减法操作，这增加了时间开销。 缺点3：引用计数器有一个严重的问题，即无法处理循环引用的情况。这是一条致命缺陷，导致在 Java 的垃圾回收器中没有使用这类算法。

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

Python如何解决循环引用？

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

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

可达性分析算法

• 以根对象集合（GC Roots）为起始点，按照从上至下的方式搜索被根对象集合所连接的目标对象是否可达。

• 使用可达性分析算法后，内存中的存活对象都会被根对象集合直接或间接连接着，搜索所走过的路径称为引用链(Reference Chain)

• 如果目标对象没有任何引用链相连，则是不可达的，就意味着该对象己经死亡，可以标记为垃圾对象。

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

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

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

• Thread – 活着的线程

• Stack Local – Java 方法的 local 变量或参数

• JNI Local – JNI 方法的 local 变量或参数

• JNI Global – 全局 JNI 引用

• Monitor Used – 所有被同步锁synchronized持有的对象

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

Stop The World

• 可达性分析算法中枚举根节点（GC Roots)会导致所有 Java 执行线程停顿。

• 分析工作必须在一个确保一致性的快照进行。

• 一致性指整个分析期间整个执行系统看起来像被冻结在某个时间点上。

• 如果出现分析过程中对象引用关系还在不断变化，则分析结果的准确性无法保证。

3、垃圾回收算法

4、四种对象引用

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

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

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

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

强引用

软引用

弱引用

虚引用

5、finalize机制

• 永远不要主动调用某个对象的 finalize()方法，应该交给垃圾回收机制调用。理由包括下面三点:
• 在 finalize() 时可能会导致对象复活。
• finalize()方法的执行时间是没有保障的，它完全由GC线程决定，极端情况下，若不发生GC，则 finalize()方法将没有执行机会。
• 一个糟糕的 finalize() 会严重影响 GC 的性能。

• 如果从所有的根节点都无法访问到某个对象，说明对象已经不再使用了。一般来说，此对象需要被回收。但事实上，也并非是"非死不可"的，这时候它们暂时处于"缓刑"阶段。一个无法触及的对象有可能在某一个条件下"复活"自己。如果这样，那么对它的回收就是不合理的。以下 3 种状态是由于 finalize()方法的存在进行的区分。只有在对象不可触及时才可以被回收。
• 可触及的：从根节点开始，可以到达这个对象。
• 可复活的：对象的所有引用都被释放，但是对象有可能在 finalize()中复活。
• 不可触及的：对象的 finalize()被调用，并且没有复活，那么就会进入不可触及状态。不可触及的对象不可能被复活，因为finalize()只会被调用一次。

• 判定一个对象 objA 是否可回收，至少要经理两次标记过程：
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 会被移出"即将回收"集合。之后，对象会再次出现没有引用存在的情况。在这个情况下，finalize()方法不会被再次调用，对象会直接编程不可触及的状态，也就是说一个对象的 finalize()方法只会被调用一次。

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

OopMap

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

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

安全点

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

• 所有方法返回之前。

• 每条 Java 编译后的字节码的边界。

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

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

安全区域

• HotSpot 使用 OopMap 把引用类型的指针记录下来，让 GC Roots 的枚举变得快速准确。

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

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

7、吞吐量和暂停时间

• 如果选择以吞吐量优先，那么必然需要降低内存回收的执行频率，但是这样会导致 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/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和SerialOld GC组合(JEP 366 )

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

• java8默认使用：Parallel Scavenge GC + Parallel Old GC

• java9默认使用：G1

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

• 追求高吞吐量：ParNew GC + CMS GC

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

2、Serial GC 和 Serial Old GC

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

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

JVM 参数：

• -XX:+UseSerialGC 同时设置新生代收集器为 Serial GC，老年代收集器为Serial Old GC。

3、ParNew GC

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

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

JVM 参数：

• -XX:+UseParNewGC 设置新生代收集器为 ParNew GC

• -XX:ParallelGCThreads 设置并行收集线程数

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 进行讲解。

JVM 参数

• -XX:+UseParallelGC 设置新生代回收器为 Parallel Scanvenge GC，老年代回收器为 PS MarkSweep（Serial Old GC）。

• -XX:+UserParallelOldGC 设置新生代回收器为 Parallel Scanvenge GC，老年代回收器为 Parallel Old GC。

• -XX:ParallelGCThreads 设置年轻代并行收集器的线程数。一般地，最好与CPU数量相等，以避免过多的线程数影响垃圾收集性能。在默认情况下，当CPU 数量小于8个， ParallelGCThreads 的值等于CPU 数量。当CPU数量大于8个，ParallelGCThreads 的值等于3+[5*CPU_Count]/8] 。

• -XX:MaxGCPauseMillis 设置垃圾收集器最大停顿时间(即STW的时间)。单位是毫秒。为了尽可能地把停顿时间控制在MaxGCPauseMills以内，收集器在工作时会调整Java堆大小或者其他一些参数。 对于用户来讲，停顿时间越短体验越好。但是在服务器端，我们注重高并发，整体的吞吐量。所以服务器端适合Parallel，进行控制。该参数使用需谨慎。

• -XX:GCTimeRatio 垃圾收集时间占总时间的比例（= 1 / (N + 1))。用于衡量吞吐量的大小。取值范围（0,100）。默认值99，也就是垃圾回收时间不超过1%。 与前一个-XX:MaxGCPauseMillis参数有一定矛盾性。暂停时间越长，Radio参数就容易超过设定的比例。

• -XX:+UseAdaptiveSizePolicy 设置Parallel Scavenge收集器具有自适应调节策略。在这种模式下，年轻代的大小、Eden和Survivor的比例、晋升老年代的对象年龄等参数会被自动调整，已达到在堆大小、吞吐量和停顿时间之间的平衡点。在手动调优比较困难的场合，可以直接使用这种自适应的方式，仅指定虚拟机的最大堆、目标的吞吐量（GCTimeRatio）和停顿时间（MaxGCPauseMills），让虚拟机自己完成调优工作。

5、CMS GC

JVM 参数：

• -XX:+UseConcMarkSweepGC 设置老年代为 CMS GC，同时自动打开 -XX:+UseParNewGC，设置新生代为ParNew GC

• -XX:+UseCMSCompactAtFullCollection 用于指定在执行完Full GC后对内存空间进行压缩整理，以此避免内存碎片的产生，默认开启。不过由于内存压缩整理过程无法并发执行，所带来的问题就是停顿时间变得更长了。

• -XX:CMSFullGCsBeforeCompaction 设置在执行多少次Full GC后对内存空间进行压缩整理。

• -XX:ParallelCMSThreads 设置 CMS 的线程数，默认为(ParallelGCThreads + 3)/4

• -XX:CMSInitiatingOccupancyFraction 设置堆内存使用率的阈值，一旦达到该阈值，便开始进行回收。
• JDK5 及以前版本的默认值为68,即当老年代的空间使用率达到 68% 时，会执行一次 CMS 回收；JDK6及以上版本默认值为92%。
• 如果内存增长缓慢，则可以设置一个稍大的值，大的阈值可以有效降低 CMS 的触发频率，减少老年代回收的次数可以较为明显地改善应用程序性能。反之，如果应用程序内存使用率增长很快，则应该降低这个阈值，以避免频繁触发老年代串行收集器。因此通过该选项便可以有效降低Full GC 的执行次数。

• -XX:+UseCMSInitiatingOccupancyOnly 关闭动态检查，动态检查是指 CMS 会根据历史记录，预测内存空间还剩多少时触发 CMS GC，一般和 -XX:CMSInitiatingOccupancyFraction 搭配使用

• -XX:+CMSScavengeBeforeRemark 在重新标记之前执行一次 Minor GC。

CMS GC的回收过程

• 初始标记阶段（Initial-Mark）：只标记出 GC Roots 直接可达的老年代对象，java7 单线程，java8 多线程，STW，速度非常快。

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

• 预清理（Concurrent-Preclean）：扫描 Dirty 对象，并标记被 Dirty 对象直接或间接引用的对象，然后清除 Card 标识。目的是为了让重新标记阶段的 STW 尽可能短，和用户线程并发执行，可设置参数不执行



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

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

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

• 并发清除阶段（Concurrent-Sweep）：清除标记阶段判断已经死亡的对象，和用户线程并发执行。

• 重置线程阶段（Concurrent-Reset）：清除内部状态，为下次回收做准备。

CMS GC的问题

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

• 在 Minor GC 的时候，新生代 Survivor 空间放不下，需要放入老年代，而老年代也放不下而产生的，这时候会报 Promotion Failed 和 Concurrent Mode Failure。通常是因为老年代虽然内存空间充足，但是存在大量内存碎片，而新生代需要晋升的对象又较大，导致因为没有足够的连续可用空间而晋升失败。

• 在 CMS GC 的时候，CMS GC 过程中同时业务线程将对象放入老年代，而此时老年代空间不足，这时候会报 Concurrent Mode Failure。

6、G1 GC

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

• 全新的分代概念。从分代上看，G1 依然属于分代型垃圾回收器。但不要求各代都是连续逻辑空间，将堆空间分为多个 Region，每个 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 收集器在有限的时间内可以获取尽可能高的收集效率。

JVM 参数：

• -XX+UseG1GC 设置垃圾回收器为 G1 GC

• -XX:G1HeapRegionSize 设置每个 region 的大小，值是 2 的幂，1MB~32MB，默认是堆内存的 1/2000

• -XX:MaxGCPauseMills 期望达到的最大 GC 停顿时间，会尽量满足不能保证一定达到，默认是 200ms

• -XX:ParallelGCThread 并行执行即 STW 阶段的工作线程数，最多 8

• -XX:ConcGCThreads 并发执行的线程数，一般为 -XX:ParallelGCThread 的四分之一

• -XX:InitiatingHeapOccupancyPercent 设置触发并发GC周期的堆占用率阈值，默认值是45%

• -XX:G1MixedGCCountTarget 一次 GC 周期最多执行 Mixed GC 的次数，默认为 8。

• -XX:G1HeapWastePercent 默认值 5%，在全局并发标记结束后能够统计出所有可被回收的垃圾占 Heap 的比例值，如果超过5%，那么就会触发之后的多轮 Mixed GC。这个参数可以控制 Mixed GC 触发的时机。

Region

• 一个 Region 有可能属于 Eden，Survivor 或者 Old/Tenured 内存区域。但是一个 Region 只可能属于一个角色。图中的 E 表示该 region 属于 Eden 内存区域，S 表示属于 Survivor 内存区域，O 表示属于 Old 内存区域。图中空白的表示未使用的内存空间。

• G1 垃圾收集器还增加了一种新的内存区域，叫做 Humongous 内存区域，如图中的 H 块。主要用于存储大对象，如果超过1.5个region，就放到 H。

设置 H 的原因： 对于堆中的大对象，默认直接会被分配到老年代，但是如果它是一个短期存在的大对象，就会对垃圾收集器造成负面影响。为了解决这个问题，G1 划分了一个 Humongous 区，它用来专门存放大对象。如果一个 H 区装不下一个大对象，那么 G1 会寻找连续的 H 区来存储。为了能找到连续的 H 区，有时候不得不启动 Full GC。G1 的大多数行为都把 H 区作为老年代的一部分来看待。

Rset（Remember Set）

• 每个 Region 都会对应一个 Rset。例如上面的 Region1、Region2、Region3 分别对应一个 Rset。

• Rset 记录了其他 Region 对当前 Region 的引用。例如上面的 Region2 的 Rset 中记录了 Region1 和 Region3 对当前 Region 的引用信息。

• 年轻代的 Region 的 RSet 只保存来自老年代的引用。这是因为年轻代的回收是针对所有年轻代 Region 的，没必要画蛇添足。所以说年轻代 Region 的 RSet 有可能是空的。

• 老年代的 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 直接引用的对象标记为灰色集合。

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

 

 

• JDK14 之前，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() 时（调用后并不会立即发生 FGC，后面会在某个时间点发生），操作系统建议执行 Full GC( -XX:+DisableExplicitGC 可禁用 )。

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

3. 方法区空间不足时，或 Metaspace Space 使用达到 MetaspaceSize 但未达到 MaxMetaspaceSize 阈值，大多情况下扩容都会触发。

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

5. Promotion Failed：通过 Minor GC 后进入老年代的平均大小大于老年代的可用内存时。由 Eden 区、From Survior 区向 To Survior 区复制时，对象大小大于 To Survior 区可用内存，则把该对象转存到老年代，且老年代的可用内存小于该对象大小时。

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

2、空间分配担保机制

• 如果大于：则此次 Minor GC 是安全的。

• 如果小于，则虚拟机会查看 HandlePromotionFailure 设置值是否允许担保失败。
• 如果 HandlePromotionFailure=true，那么会继续检查老年代最大可用连续空间是否大于历次晋升到老年代的对象的平均大小，如果大于，则尝试进行一次 Minor GC，但这次 Minor GC 依然是有风险的。
• 如果小于或者HandlePromotionFailure=false ，则改为进行一次 Full GC。

3、动态年龄判断

• 大对象直接进入老年代。那多大的对象是大对象？这个阈值通过 -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()，这里只做了指针的移动，但是引用未手动置空，所以是不会释放内存的。可以改成这样。