【后端开发笔记】JVM底层原理-垃圾回收篇

内存管理

堆空间基本结构

现在收集器基本都采用分代垃圾收集算法，所以 Java 堆被划分为了几个不同的区域

JDK 7 及之前的版本中，堆内存通常分为三部分：

1. 新生代内存
2. 老生代
3. 永久代

下图所示的 Eden 区、两个 Survivor 区 S0 和 S1 都属于新生代，中间一层属于老年代，最下面一层属于永久代。

JDK 8 版本之后 PermGen(永久) 已被 Metaspace(元空间) 取代，元空间使用的是直接内存 。

内存分配

两种方式

不分配内存的对象无法进行其他操作，JVM 为对象分配内存的过程：首先计算对象占用空间大小，接着在堆中划分一块内存给新对象

• 如果内存规整 ，使用指针碰撞 。所有用过的内存在一边，空闲的内存在另外一边，中间有一个指针 作为分界点的指示器，分配内存就仅仅是把指针向空闲那边挪动一段与对象大小相等的距离
• 如果内存不规整 ，虚拟机需要维护一个空闲列表 分配。已使用的内存和未使用的内存相互交错，虚拟机维护了一个列表，记录上哪些内存块是可用的，再分配的时候从列表中找到一块足够大的空间划分给对象实例，并更新列表上的内容

TLAB

TLAB： Thread Local Allocation Buffer，为每个线程在堆内单独分配了一个缓冲区，多线程分配内存时，使用 TLAB 可以避免线程安全问题，同时还能够提升内存分配的吞吐量，这种内存分配方式叫做快速分配策略

• 栈上分配 使用的是栈来进行对象内存的分配
• TLAB 分配 使用的是 Eden 区域 进行内存分配，属于堆内存

堆区是线程共享区域，任何线程都可以访问到堆区中的共享数据，由于对象实例的创建在 JVM 中非常频繁，因此在并发环境下为避免多个线程操作同一地址，需要使用加锁等机制，进而影响分配速度

问题：堆空间都是共享的么？ 不一定，因为还有 TLAB，在堆中划分出一块区域，为每个线程所独占

JVM 是将 TLAB 作为内存分配的首选，但不是所有的对象实例都能够在 TLAB 中成功分配内存，一旦对象在 TLAB 空间分配内存失败时，JVM 就会通过使用加锁机制确保数据操作的原子性，从而直接在堆中分配内存

栈上分配优先于 TLAB 分配进行，逃逸分析中若可进行栈上分配优化，会优先进行对象栈上直接分配内存

参数设置：

• -XX:UseTLAB：设置是否开启 TLAB 空间
• -XX:TLABWasteTargetPercent：设置 TLAB 空间所占用 Eden 空间的百分比大小，默认情况下 TLAB 空间的内存非常小，仅占有整个 Eden 空间的1%
• -XX:TLABRefillWasteFraction：指当 TLAB 空间不足，请求分配的对象内存大小超过此阈值时不会进行 TLAB 分配，直接进行堆内存分配，否则还是会优先进行 TLAB 分配

对象优先在 Eden 区分配

大多数情况下，对象在新生代中 Eden 区分配。当 Eden 区没有足够空间进行分配时，虚拟机将发起一次 Minor GC。通过 分配担保机制 把新生代的对象提前转移到老年代中去，老年代上的空间足够存放对象，所以不会出现 Full GC。执行 Minor GC 后，后面分配的对象如果能够存在 Eden 区的话，还是会在 Eden 区分配内存。

大对象直接进入老年代

大对象就是需要大量连续内存空间的对象（比如：字符串、数组）。

行为由虚拟机动态决定的，旨在避免将大对象放入新生代，从而减少新生代的垃圾回收频率和成本。

长期存活的对象将进入老年代

虚拟机给每个对象一个对象年龄（Age）计数器。

大部分情况，对象都会首先在 Eden 区域分配。若对象在 Eden 出生并经过第一次 Minor GC 后仍然能够存活，并且能被 Survivor 容纳的话，将被移动到 Survivor 空间（s0 或者 s1）中，并将对象年龄设为 1(Eden 区->Survivor 区后对象的初始年龄变为 1)。

对象在 Survivor 中每熬过一次 MinorGC ，年龄就增加 1 岁，当它的年龄增加到一定程度（默认为 15 岁），就会被晋升到老年代中。对象晋升到老年代的年龄阈值，可以通过参数 -XX:MaxTenuringThreshold 来设置。

主要进行GC的区域

HotSpot VM 的实现，主要分为两大类：

1. 部分收集：

• • 新生代收集：只对新生代进行收集
  • 老年代收集：只对老年代进行垃圾收集
  • 混合收集：对整个新生代和部分老年代进行垃圾回收

1. 整堆收集：收集整个 Java 堆和方法区

空间分配担保

空间分配担保是为了确保在 Minor GC 之前老年代本身还有容纳新生代所有对象的剩余空间。

垃圾回收大致流程：

1. 发生 Minor GC，JVM 开始清理新生代的 Eden 区和 From Survivor 区
2. GC 会找出仍然存活的对象
3. 通常，这些存活对象会被移动到新生代内部的 To Survivor 区
4. 但是，有一种特殊情况：某个存活对象已经"年纪很大"（在 Survivor 区来回复制多次，年龄达到了阈值 -XX:MaxTenuringThreshold），或者 To Survivor 区空间不足以存放所有存活对象，那么这些对象就需要被"晋升"（Promote）到老年代

由此引发一个问题：如果老年代也没有足够的空间 来容纳这些即将晋升的对象，这次 Minor GC 就会失败，进而触发一次代价高昂的 Full GC（通常包括对整个堆和方法区的回收），这会导致长时间的停顿（STW），对应用性能影响极大。

因此在真正执行 Minor GC 之前，先做一个风险评估，确保老年代有足够的空间来容纳可能晋升的所有对象，从而避免因晋升失败而导致的 Full GC。

工作流程

1. 发生 Minor GC 前：JVM 不会立即开始回收，而是先进行检查。
2. 计算晋升平均值 ：JVM 会统计之前每次 Minor GC 后晋升到老年代的对象的平均大小。这是一个经验值。
3. 进行担保检查 ：如果老年代的剩余连续空间 > 历次晋升到老年代的对象的平均大小 ，那么 JVM 会认为这次冒险是安全的，可以正常进行 Minor GC。即使这次晋升的对象比平均略多，老年代也大概率能装下。
4. 如果检查不通过 ：如果老年代的剩余空间小于这个平均值，则说明冒险的风险很大。此时，JVM 不会直接进行冒险的 Minor GC，而是会主动触发一次 Full GC 。Full GC 会同时清理老年代和年轻代，腾出空间。Full GC 结束后，**再来执行 Minor GC，**这样就能保证晋升一定会成功。

|----------|---------------------------------------------------------------------------|
| 特性 | 描述 |
| 目的 | 避免因年轻代存活对象晋升到老年代时空间不足而导致的 Full GC，是一种风险规避策略。 |
| 触发时机 | 在每一次 Minor GC 发生之前。 |
| 判断依据 | 比较老年代的剩余空间 和历次晋升对象的平均大小。 |
| 成功 | 剩余空间 > 平均大小 -> 执行 Minor GC。 |
| 失败 | 剩余空间 < 平均大小 -> 先执行 Full GC，再执行 Minor GC。 |
| 重要性 | 是一种重要的性能优化手段，虽然可能因为担保失败而主动触发 Full GC，但相比晋升失败被迫触发的 Full GC，其发生频率和不确定性要低得多。 |

逃逸分析

虚拟机分析新创建的对象的使用范围，判断是否会被其他方法体引用，进而决定是否在堆上分配内存的技术。逃逸分析并不是直接的优化手段，而是一个代码分析方式，通过动态分析对象的作用域，为优化手段如栈上分配、标量替换和同步消除等提供依据，发生逃逸行为的情况有两种：方法逃逸和线程逃逸

/*

即时编译（Just-in-time Compilation，JIT）是一种通过在运行时将字节码翻译为机器码，从而改善性能的技术，在 HotSpot 实现中有多种选择：C1、C2 和 C1+C2，分别对应 Client、Server 和分层编译

• C1 编译速度快，优化方式比较保守；C2 编译速度慢，优化方式比较激进
• C1+C2 在开始阶段采用 C1 编译，当代码运行到一定热度之后采用 C2 重新编译

*/

逃逸状态

1. 方法逃逸：当一个对象在方法中定义之后，被外部方法引用

• 全局逃逸：一个对象的作用范围逃出了当前方法或者当前线程，比如对象是一个静态变量、全局变量赋值、已经发生逃逸的对象、作为当前方法的返回值
• 参数逃逸：一个对象被作为方法参数传递或者被参数引用

1. 线程逃逸：如类变量或实例变量，可能被其它线程访问到

优化对象

如果不存在逃逸行为，则可以对该对象进行如下优化：同步消除、标量替换和栈上分配

1. 同步消除

线程同步本身比较耗时，如果确定一个对象不会逃逸出线程 ，不被其它线程访问到，那对象的读写就不会存在竞争，则可以消除对该对象的同步锁 ，通过 -XX:+EliminateLocks 可以开启同步消除 ( - 号关闭)

1. 标量替换

• 标量替换：如果把一个对象拆散，将其成员变量恢复到基本类型来访问
• 标量 (scalar) ：不可分割的量，如基本数据类型和 reference 类型聚合量 (Aggregate)：一个数据可以继续分解，对象一般是聚合量
• 如果逃逸分析发现一个对象不会被外部访问，并且该对象可以被拆散，那么经过优化之后，并不直接生成该对象，而是将该对象成员变量分解若干个被这个方法使用的成员变量所代替
• 参数设置：

• • -XX:+EliminateAllocations：开启标量替换
  • -XX:+PrintEliminateAllocations：查看标量替换情况

1. 栈上分配

JIT 编译器在编译期间根据逃逸分析的结果，如果一个对象没有逃逸出方法的话，就可能被优化成栈上分配。分配完成后，继续在调用栈内执行，最后线程结束，栈空间被回收，局部变量对象也被回收，这样就无需 GC

User 对象的作用域局限在方法 fn 中，可以使用标量替换的优化手段在栈上分配对象的成员变量，这样就不会生成 User 对象，大大减轻 GC 的压力

分代思想

Java8 时，堆被分为了两份：新生代和老年代（1:2），在 Java7 时，还存在一个永久代

• 新生代使用：复制算法
• 老年代使用：标记 - 清除 或者 标记 - 整理 算法

Minor GC 和 Full GC：

• Minor GC：回收新生代 ，新生代对象存活时间很短，所以 Minor GC 会频繁执行，执行的速度比较快
• Full GC：回收老年代和新生代 ，老年代对象其存活时间长，所以 Full GC 很少执行，执行速度会比 Minor GC 慢很多

Eden 和 Survivor 大小比例默认为 8:1:1

分代分配

工作机制：

• 对象优先在 Eden 分配：当创建一个对象的时候，对象会被分配在新生代的 Eden 区，当 Eden 区要满了时候，触发 YoungGC
• 当进行 YoungGC 后，此时在 Eden 区存活的对象被移动到 to 区，并且当前对象的年龄会加 1，清空 Eden 区
• 当再一次触发 YoungGC 的时候，会把 Eden 区中存活下来的对象和 to 中的对象，移动到 from 区中，这些对象的年龄会加 1，清空 Eden 区和 to 区
• To 区永远是空 Survivor 区，From 区是有数据的，每次 MinorGC 后两个区域互换
• From 区和 To 区 也可以叫做 S0 区和 S1 区

晋升到老年代：

• 长期存活的对象进入老年代 ：为对象定义年龄计数器，对象在 Eden 出生并经过 Minor GC 依然存活，将移动到 Survivor 中，年龄就增加 1 岁，增加到一定年龄则移动到老年代中-XX:MaxTenuringThreshold：定义年龄的阈值，对象头中用 4 个 bit 存储，所以最大值是 15，默认也是 15
• 大对象直接进入老年代 ：需要连续内存空间的对象，最典型的大对象是很长的字符串以及数组；避免在 Eden 和 Survivor 之间的大量复制；经常出现大对象会提前触发 GC 以获取足够的连续空间分配给大对象-XX:PretenureSizeThreshold：大于此值的对象直接在老年代分配
• 动态对象年龄判定：如果在 Survivor 区中相同年龄的对象的所有大小之和超过 Survivor 空间的一半，年龄大于等于该年龄的对象就可以直接进入老年代

空间分配担保

• 在发生 Minor GC 之前，虚拟机先检查老年代最大可用的连续空间是否大于新生代所有对象总空间，如果条件成立的话，那么 Minor GC 可以确认是安全的
• 如果不成立，虚拟机会查看 HandlePromotionFailure 的值是否允许担保失败，如果允许那么就会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小，如果大于将尝试着进行一次 Minor GC；如果小于或者 HandlePromotionFailure 的值不允许冒险，那么就要进行一次 Full GC

回收策略

触发条件

内存垃圾回收机制主要集中的区域就是线程共享区域：堆和方法区

Minor GC 触发条件非常简单，当 Eden 空间满时，就将触发一次 Minor GC

FullGC 同时回收新生代、老年代和方法区，只会存在一个 FullGC 的线程进行执行，其他的线程全部会被挂起，有以下触发条件：

• 调用 System.gc()：

• • 在默认情况下，通过 System.gc() 或 Runtime.getRuntime().gc() 的调用，会显式触发 FullGC，同时对老年代和新生代进行回收，但是虚拟机不一定真正去执行，无法保证对垃圾收集器的调用
  • 不建议使用这种方式，应该让虚拟机管理内存。一般情况下，垃圾回收应该是自动进行的，无须手动触发；在一些特殊情况下，如正在编写一个性能基准，可以在运行之间调用 System.gc()

• 老年代空间不足：

• • 为了避免引起的 Full GC，应当尽量不要创建过大的对象以及数组
  • 通过 -Xmn 参数调整新生代的大小，让对象尽量在新生代被回收掉不进入老年代，可以通过 -XX:MaxTenuringThreshold 调大对象进入老年代的年龄，让对象在新生代多存活一段时间

• 空间分配担保失败
• JDK 1.7 及以前的永久代（方法区）空间不足
• Concurrent Mode Failure：执行 CMS GC 的过程中同时有对象要放入老年代，而此时老年代空间不足（可能是 GC 过程中浮动垃圾过多导致暂时性的空间不足），便会报 Concurrent Mode Failure 错误，并触发 Full GC

安全区域

安全点 (Safepoint)：程序执行时并非在所有地方都能停顿下来开始 GC，只有在安全点才能停下

• Safe Point 的选择很重要，如果太少可能导致 GC 等待的时间太长，如果太多可能导致运行时的性能问题
• 大部分指令的执行时间都非常短，通常会根据是否具有让程序长时间执行的特征为标准，选择些执行时间较长的指令作为 Safe Point， 如方法调用、循环跳转和异常跳转等

在 GC 发生时，让所有线程都在最近的安全点停顿下来的方法：

• 抢先式中断：没有虚拟机采用，首先中断所有线程，如果有线程不在安全点，就恢复线程让线程运行到安全点
• 主动式中断：设置一个中断标志，各个线程运行到各个 Safe Point 时就轮询这个标志，如果中断标志为真，则将自己进行中断挂起

问题：Safepoint 保证程序执行时，在不太长的时间内就会遇到可进入 GC 的 Safepoint，但是当线程处于 Waiting 状态或 Blocked 状态，线程无法响应 JVM 的中断请求，运行到安全点去中断挂起，JVM 也不可能等待线程被唤醒，对于这种情况，需要安全区域来解决

安全区域 (Safe Region)：指在一段代码片段中，对象的引用关系不会发生变化，在这个区域中的任何位置开始 GC 都是安全的

运行流程：

• 当线程运行到 Safe Region 的代码时，首先标识已经进入了 Safe Region，如果这段时间内发生 GC，JVM 会忽略标识为 Safe Region 状态的线程
• 当线程即将离开 Safe Region 时，会检查 JVM 是否已经完成 GC，如果完成了则继续运行，否则线程必须等待 GC 完成，收到可以安全离开 Safe Region 的信号

垃圾判断

如果一个或多个对象没有任何的引用指向它了，那么这个对象现在就是垃圾

作用：释放没用的对象，清除内存里的记录碎片，碎片整理将所占用的堆内存移到堆的一端，以便 JVM 将整理出的内存分配给新的对象

垃圾收集主要是针对堆 和方法区 进行，程序计数器、虚拟机栈和本地方法栈这三个区域属于线程私有的，只存在于线程的生命周期内，线程结束之后就会消失，因此不需要对这三个区域进行垃圾回收

在堆里存放着几乎所有的 Java 对象实例，在 GC 执行垃圾回收之前 ，首先需要区分出内存中哪些是存活对象，哪些是已经死亡的对象。只有被标记为己经死亡的对象，GC 才会在执行垃圾回收时，释放掉其所占用的内存空间，因此这个过程可以称为垃圾标记阶段，判断对象存活一般有两种方式：引用计数算法 和可达性分析算法

引用计数法

引用计数算法（Reference Counting）：对每个对象保存一个整型的引用计数器属性，用于记录对象被引用的情况。对于一个对象 A，只要有任何一个对象引用了 A，则 A 的引用计数器就加 1；当引用失效时，引用计数器就减 1；当对象 A 的引用计数器的值为 0，即表示对象A不可能再被使用，可进行回收（Java 没有采用）

优点：

• 回收没有延迟性，无需等到内存不够的时候才开始回收，运行时根据对象计数器是否为 0，可以直接回收
• 在垃圾回收过程中，应用无需挂起；如果申请内存时，内存不足，则立刻报 OOM 错误
• 区域性，更新对象的计数器时，只是影响到该对象，不会扫描全部对象

缺点：

• 每次对象被引用时，都需要去更新计数器，有一点时间开销
• 浪费 CPU 资源，即使内存够用，仍然在运行时进行计数器的统计。
• 无法解决循环引用问题，会引发内存泄露（最大的缺点）

可达性分析

GC Roots

可达性分析算法：也可以称为根搜索算法、追踪性垃圾收集

GC Roots 对象：

• 虚拟机栈中局部变量表中引用的对象：各个线程被调用的方法中使用到的参数、局部变量等
• 本地方法栈中引用的对象
• 堆中类静态属性引用的对象
• 方法区中的常量引用的对象
• 字符串常量池（string Table）里的引用
• 同步锁 synchronized 持有的对象

GC Roots 是一组活跃的引用，不是对象，放在 GC Roots Set 集合

工作原理

可达性分析算法以根对象集合（GCRoots）为起始点，从上至下的方式搜索被根对象集合所连接的目标对象

分析工作必须在一个保障一致性的快照中进行，否则结果的准确性无法保证，这也是导致 GC 进行时必须 Stop The World 的一个原因

基本原理：

• 可达性分析算法后，内存中的存活对象都会被根对象集合直接或间接连接着，搜索走过的路径称为引用链
• 如果目标对象没有任何引用链相连，则是不可达的，就意味着该对象己经死亡，可以标记为垃圾对象
• 在可达性分析算法中，只有能够被根对象集合直接或者间接连接的对象才是存活对象

三色标记

标记算法

三色标记法把遍历对象图过程中遇到的对象，标记成以下三种颜色：

• 白色：尚未访问过
• 灰色：本对象已访问过，但是本对象引用到的其他对象尚未全部访问
• 黑色：本对象已访问过，而且本对象引用到的其他对象也全部访问完成

当 Stop The World (STW) 时，对象间的引用是不会发生变化的，可以轻松完成标记，遍历访问过程为：

1. 初始时，所有对象都在白色集合
2. 将 GC Roots 直接引用到的对象挪到灰色集合
3. 从灰色集合中获取对象：

• • 将本对象引用到的其他对象全部挪到灰色集合中
  • 将本对象挪到黑色集合里面

1. 重复步骤 3，直至灰色集合为空时结束
2. 结束后，仍在白色集合的对象即为 GC Roots 不可达，可以进行回收

并发标记

并发标记时，对象间的引用可能发生变化，多标和漏标的情况就有可能发生

多标情况： 当 E 变为灰色或黑色时，其他线程断开的 D 对 E 的引用，导致这部分对象仍会被标记为存活，本轮 GC 不会回收这部分内存，这部分本应该回收但是没有回收到的内存，被称之为 浮动垃圾

• 针对并发标记开始后的新对象，通常的做法是直接全部当成黑色，也算浮动垃圾
• 浮动垃圾并不会影响应用程序的正确性，只是需要等到下一轮垃圾回收中才被清除

漏标情况：

• 条件一：灰色对象断开了对一个白色对象的引用（直接或间接），即灰色对象原成员变量的引用发生了变化
• 条件二：其他线程中修改了黑色对象，插入了一条或多条对该白色对象的新引用
• 结果：导致该白色对象当作垃圾被 GC，影响到了程序的正确性

为了解决问题，可以操作上面三步，将对象 G 记录起来，然后作为灰色对象再进行遍历，比如放到一个特定的集合，等初始的 GC Roots 遍历完（并发标记），再遍历该集合（重新标记）

所以重新标记需要 STW，应用程序一直在运行，该集合可能会一直增加新的对象，导致永远都运行不完

解决方法：添加读写屏障，读屏障拦截第一步，写屏障拦截第二三步，在读写前后进行一些后置处理：

• 写屏障 + 增量更新：黑色对象新增引用，会将黑色对象变成灰色对象，最后对该节点重新扫描增量更新破坏了条件二，从而保证了不会漏标缺点：对黑色变灰的对象重新扫描所有引用，比较耗费时间
• 写屏障+ SATB：当原来成员变量的引用发生变化之前，记录下原来的引用对象保留 GC 开始时的对象图，即原始快照 SATB，当 GC Roots 确定后，对象图就已经确定，那后续的标记也应该是按照这个时刻的对象图走，如果期间对白色对象有了新的引用会记录下来，并且将白色对象变灰（说明可达了，并且原始快照中本来就应该是灰色对象），最后重新扫描该对象的引用关系SATB (Snapshot At The Beginning) 破坏了条件一，从而保证了不会漏标
• 读屏障 (Load Barrier)：破坏条件二，黑色对象引用白色对象的前提是获取到该对象，此时读屏障发挥作用

以 Java HotSpot VM 为例，其并发标记时对漏标的处理方案如下：

• CMS：写屏障 + 增量更新
• G1：写屏障 + SATB
• ZGC：读屏障

哪些对象可以作为GC Roots

1. 虚拟机栈(栈帧中的局部变量表)中引用的对象
2. 本地方法栈(Native 方法)中引用的对象
3. 方法区中类静态属性引用的对象
4. 方法区中常量引用的对象
5. 所有被同步锁持有的对象
6. JNI引用的对象

引用类型

四种引用类型

1. 强引用：被强引用关联的对象不会被回收，只有所有 GCRoots 都不通过强引用引用该对象，才能被垃圾回收

• • 强引用可以直接访问目标对象
  • 虚拟机宁愿抛出 OOM 异常，也不会回收强引用所指向对象
  • 强引用可能导致内存泄漏

1. 软引用（SoftReference）：被软引用关联的对象只有在内存不够的情况下才会被回收

• • **仅（可能有强引用，一个对象可以被多个引用）**有软引用引用该对象时，在垃圾回收后，内存仍不足时会再次出发垃圾回收，回收软引用对象
  • 配合引用队列来释放软引用自身，在构造软引用时，可以指定一个引用队列，当软引用对象被回收时，就会加入指定的引用队列，通过这个队列可以跟踪对象的回收情况
  • 软引用通常用来实现内存敏感的缓存，比如高速缓存就有用到软引用；如果还有空闲内存，就可以暂时保留缓存，当内存不足时清理掉，这样就保证了使用缓存的同时不会耗尽内存

1. 弱引用：被弱引用关联的对象一定会被回收，只能存活到下一次垃圾回收发生之前

• • 仅有弱引用引用该对象时，在垃圾回收时，无论内存是否充足，都会回收弱引用对象
  • 配合引用队列来释放弱引用自身
  • WeakHashMap 用来存储图片信息，可以在内存不足的时候及时回收，避免了 OOM

1. 虚引用（PhantomReference）：也称为幽灵引用或者幻影引用，是所有引用类型中最弱的一个

• • 一个对象是否有虚引用的存在，不会对其生存时间造成影响，也无法通过虚引用得到一个对象
  • 为对象设置虚引用的唯一目的是在于跟踪垃圾回收过程，能在这个对象被回收时收到一个系统通知
  • 必须配合引用队列使用，主要配合 ByteBuffer 使用，被引用对象回收时会将虚引用入队，由 Reference Handler 线程调用虚引用相关方法释放直接内存

1. 终结器引用

无用属性

无用类

方法区主要回收的是无用的类

判定一个类是否是无用的类，需要同时满足下面 3 个条件：

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

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

废弃常量

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

静态变量

类加载时（第一次访问），这个类中所有静态成员就会被加载到静态变量区，该区域的成员一旦创建，直到程序退出才会被回收

如果是静态引用类型的变量，静态变量区只存储一份对象的引用地址，真正的对象在堆内，如果要回收该对象可以设置引用为 null

回收算法

复制算法

复制算法的核心就是，将原有的内存空间一分为二，每次只用其中的一块 ，在垃圾回收时，将正在使用的对象 复制到另一个内存空间中，然后将该内存空间清理，交换两个内存的角色，完成垃圾的回收

应用场景：如果内存中的垃圾对象较多，需要复制的对象就较少，这种情况下适合使用该方式并且效率比较高，反之则不适合

优点

• 没有标记和清除过程，实现简单，运行速度快
• 复制过去以后保证空间的连续性，不会出现碎片问题

缺点

• 主要不足是只使用了内存的一半
• 对于 G1 这种分拆成为大量 region 的 GC，复制而不是移动，意味着 GC 需要维护 region 之间对象引用关系，不管是内存占用或者时间开销都不小

现在的商业虚拟机都采用这种收集算法回收新生代 ，因为新生代 GC 频繁并且对象的存活率不高 ，但是并不是划分为大小相等的两块，而是一块较大的 Eden 空间和两块较小的 Survivor 空间

标记清除

标记清除算法，是将垃圾回收分为两个阶段，分别是标记和清除

• 标记 ：Collector 从引用根节点开始遍历，标记所有被引用的对象，一般是在对象的 Header 中记录为可达对象，标记的是引用的对象，不是垃圾
• 清除 ：Collector 对堆内存从头到尾进行线性的遍历，如果发现某个对象在其 Header 中没有标记为可达对象，则将其回收，把分块连接到空闲列表的单向链表，判断回收后的分块与前一个空闲分块是否连续，若连续会合并这两个分块，之后进行分配时只需要遍历这个空闲列表，就可以找到分块
• 分配阶段：程序会搜索空闲链表寻找空间大于等于新对象大小 size 的块 block，如果找到的块等于 size，会直接返回这个分块；如果找到的块大于 size，会将块分割成大小为 size 与 block - size 的两部分，返回大小为 size 的分块，并把大小为 block - size 的块返回给空闲列表

缺点

• 标记和清除过程效率都不高
• 会产生大量不连续的内存碎片，导致无法给大对象分配内存，需要维护一个空闲链表

标记整理

标记整理（压缩）算法是在标记清除算法的基础之上，做了优化改进的算法

标记阶段和标记清除算法一样，也是从根节点开始，对对象的引用进行标记，在清理阶段，并不是简单的直接清理可回收对象，而是将存活对象都向内存另一端移动 ，然后清理边界以外的垃圾，从而解决了碎片化的问题

优点：不会产生内存碎片

缺点：需要移动大量对象，处理效率比较低

|------|------------|--------------|-----------------------|
| | Mark-Sweep | Mark-Compact | Copying |
| 速度 | 中等 | 最慢 | 最快 |
| 空间开销 | 少（但会堆积碎片） | 少（不堆积碎片） | 通常需要活对象的 2 倍大小（不堆积碎片） |
| 移动对象 | 否 | 是 | 是 |

垃圾回收器

概述

垃圾收集器分类：

• 按线程数分（垃圾回收线程数），可以分为串行垃圾回收器和并行垃圾回收器

• • 除了 CMS 和 G1 之外，其它垃圾收集器都是以串行的方式执行

• 按照工作模式分，可以分为并发式垃圾回收器和独占式垃圾回收器

• • 并发式垃圾回收器与应用程序线程交替工作，以尽可能减少应用程序的停顿时间
  • 独占式垃圾回收器（Stop the world）一旦运行，就停止应用程序中的所有用户线程，直到垃圾回收过程完全结束

• 按碎片处理方式分，可分为压缩式垃圾回收器和非压缩式垃圾回收器

• • 压缩式垃圾回收器在回收完成后进行压缩整理，消除回收后的碎片，再分配对象空间使用指针碰撞
  • 非压缩式的垃圾回收器不进行这步操作，再分配对象空间使用空闲列表

• 按工作的内存区间分，又可分为年轻代垃圾回收器和老年代垃圾回收器

GC 性能指标：

• 吞吐量：程序的运行时间占总运行时间的比例（总运行时间 = 程序的运行时间 + 内存回收的时间）
• 垃圾收集开销：吞吐量的补数，垃圾收集所用时间与总运行时间的比例
• 暂停时间：执行垃圾收集时，程序的工作线程被暂停的时间
• 收集频率：相对于应用程序的执行，收集操作发生的频率
• 内存占用：Java 堆区所占的内存大小
• 快速：一个对象从诞生到被回收所经历的时间

垃圾收集器的组合关系：

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

老年代收集器：Serial old、Parallel old、CMS

整堆收集器：G1

• 红色虚线在 JDK9 移除、绿色虚线在 JDK14 弃用该组合、青色虚线在 JDK14 删除 CMS 垃圾回收器

查看默认的垃圾收回收器：

• -XX:+PrintcommandLineFlags：查看命令行相关参数（包含使用的垃圾收集器）
• 使用命令行指令：jinfo -flag 相关垃圾回收器参数 进程 ID

Serial

Serial：串行垃圾收集器，作用于新生代，是指使用单线程进行垃圾回收，采用复制算法，新生代基本都是复制算法

STW（Stop-The-World）：垃圾回收时，只有一个线程在工作，并且 Java 应用中的所有线程都要暂停，等待垃圾回收的完成

Serial old ：执行老年代垃圾回收的串行收集器，内存回收算法使用的是标记-整理算法，同样也采用了串行回收和 STW 机制

• Serial old 是 Client 模式下默认的老年代的垃圾回收器
• Serial old 在 Server 模式下主要有两个用途：

• • 在 JDK 1.5 以及之前版本（Parallel Old 诞生以前）中与 Parallel Scavenge 收集器搭配使用
  • 作为老年代 CMS 收集器的后备垃圾回收方案，在并发收集发生 Concurrent Mode Failure 时使用

开启参数：-XX:+UseSerialGC 等价于新生代用 Serial GC 且老年代用 Serial old GC

优点：简单而高效（与其他收集器的单线程比），对于限定单个 CPU 的环境来说，Serial 收集器由于没有线程交互的开销，可以获得最高的单线程收集效率

缺点：对于交互性较强的应用而言，这种垃圾收集器是不能够接受的，比如 JavaWeb 应用

ParNew

Par 是 Parallel 并行的缩写，New 是只能处理的是新生代

并行垃圾收集器在串行垃圾收集器的基础之上做了改进，采用复制算法，将单线程改为了多线程进行垃圾回收，可以缩短垃圾回收的时间

对于其他的行为（收集算法、stop the world、对象分配规则、回收策略等）同 Serial 收集器一样，应用在年轻代，除 Serial 外，只有ParNew GC 能与 CMS 收集器配合工作

相关参数：

• -XX：+UseParNewGC：表示年轻代使用并行收集器，不影响老年代
• -XX:ParallelGCThreads：默认开启和 CPU 数量相同的线程数

ParNew 是很多 JVM 运行在 Server 模式下新生代的默认垃圾收集器

• 对于新生代，回收次数频繁，使用并行方式高效
• 对于老年代，回收次数少，使用串行方式节省资源（CPU 并行需要切换线程，串行可以省去切换线程的资源）

Parallel

Parallel Scavenge 收集器是应用于新生代的并行垃圾回收器，采用复制算法、并行回收和 Stop the World 机制

Parallel Old 收集器：是一个应用于老年代的并行垃圾回收器，采用标记-整理算法

对比其他回收器：

• 其它收集器目标是尽可能缩短垃圾收集时用户线程的停顿时间
• Parallel 目标是达到一个可控制的吞吐量，被称为吞吐量优先收集器
• Parallel Scavenge 对比 ParNew 拥有自适应调节策略，可以通过一个开关参数打开 GC Ergonomics

应用场景：

• 停顿时间越短就越适合需要与用户交互的程序，良好的响应速度能提升用户体验
• 高吞吐量可以高效率地利用 CPU 时间，尽快完成程序的运算任务，适合在后台运算而不需要太多交互

停顿时间和吞吐量的关系：新生代空间变小 → 缩短停顿时间 → 垃圾回收变得频繁 → 导致吞吐量下降

在注重吞吐量及 CPU 资源敏感的场合，都可以优先考虑 Parallel Scavenge + Parallel Old 收集器，在 Server 模式下的内存回收性能很好，Java8 默认是此垃圾收集器组合

参数配置：

• -XX：+UseParallelGC：手动指定年轻代使用 Paralle 并行收集器执行内存回收任务
• -XX：+UseParalleloldcc：手动指定老年代使用并行回收收集器执行内存回收任务

• • 上面两个参数，默认开启一个，另一个也会被开启（互相激活），默认 JDK8 是开启的

• -XX:+UseAdaptivesizepplicy：设置 Parallel Scavenge 收集器具有自适应调节策略，在这种模式下，年轻代的大小、Eden 和 Survivor 的比例、晋升老年代的对象年龄等参数会被自动调整，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量
• -XX:ParallelGcrhreads：设置年轻代并行收集器的线程数，一般与 CPU 数量相等，以避免过多的线程数影响垃圾收集性能

• • 在默认情况下，当 CPU 数量小于 8 个，ParallelGcThreads 的值等于 CPU 数量
  • 当 CPU 数量大于 8 个，ParallelGCThreads 的值等于 3+[5*CPU Count]/8]

• -XX:MaxGCPauseMillis：设置垃圾收集器最大停顿时间（即 STW 的时间），单位是毫秒

• • 对于用户来讲，停顿时间越短体验越好；在服务器端，注重高并发，整体的吞吐量
  • 为了把停顿时间控制在 MaxGCPauseMillis 以内，收集器在工作时会调整 Java 堆大小或其他一些参数

• -XX:GCTimeRatio：垃圾收集时间占总时间的比例 =1/(N+1)，用于衡量吞吐量的大小

• • 取值范围（0，100）。默认值 99，也就是垃圾回收时间不超过 1
  • 与 -xx:MaxGCPauseMillis 参数有一定矛盾性，暂停时间越长，Radio 参数就容易超过设定的比例

CMS

CMS 全称 Concurrent Mark Sweep，是一款并发的、使用标记-清除 算法、针对老年代的垃圾回收器，其最大特点是让垃圾收集线程与用户线程同时工作

CMS 收集器的关注点是尽可能缩短垃圾收集时用户线程的停顿时间，停顿时间越短（低延迟）越适合与用户交互的程序，良好的响应速度能提升用户体验

分为以下四个流程：

• 初始标记：使用 STW 出现短暂停顿，仅标记一下 GC Roots 能直接关联到的对象，速度很快
• 并发标记：进行 GC Roots 开始遍历整个对象图，在整个回收过程中耗时最长，不需要 STW，可以与用户线程并发运行
• 重新标记：修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象，比初始标记时间长但远比并发标记时间短，需要 STW（不停顿就会一直变化，采用写屏障 + 增量更新来避免漏标情况）
• 并发清除：清除标记为可以回收对象，不需要移动存活对象，所以这个阶段可以与用户线程同时并发的

Mark Sweep 会造成内存碎片，不把算法换成 Mark Compact 的原因：Mark Compact 算法会整理内存，导致用户线程使用的对象的地址改变，影响用户线程继续执行

在整个过程中耗时最长的并发标记和并发清除过程中，收集器线程都可以与用户线程一起工作，不需要进行停顿

优点：并发收集、低延迟

缺点：

• 吞吐量降低：在并发阶段虽然不会导致用户停顿，但是会因为占用了一部分线程而导致应用程序变慢，CPU 利用率不够高
• CMS 收集器无法处理浮动垃圾，可能出现 Concurrent Mode Failure 导致另一次 Full GC 的产生浮动垃圾是指并发清除阶段由于用户线程继续运行而产生的垃圾（产生了新对象），这部分垃圾只能到下一次 GC 时才能进行回收。由于浮动垃圾的存在，CMS 收集需要预留出一部分内存，不能等待老年代快满的时候再回收。如果预留的内存不够存放浮动垃圾，就会出现 Concurrent Mode Failure，这时虚拟机将临时启用 Serial Old 来替代 CMS，导致很长的停顿时间
• 标记 - 清除算法导致的空间碎片，往往出现老年代空间无法找到足够大连续空间来分配当前对象，不得不提前触发一次 Full GC；为新对象分配内存空间时，将无法使用指针碰撞（Bump the Pointer）技术，而只能够选择空闲列表（Free List）执行内存分配

参数设置：

• -XX：+UseConcMarkSweepGC：手动指定使用 CMS 收集器执行内存回收任务开启该参数后会自动将 -XX:+UseParNewGC 打开，即：ParNew + CMS + Serial old的组合
• -XX:CMSInitiatingoccupanyFraction：设置堆内存使用率的阈值，一旦达到该阈值，便开始进行回收

• • JDK5 及以前版本的默认值为 68，即当老年代的空间使用率达到 68% 时，会执行一次CMS回收
  • JDK6 及以上版本默认值为 92%

• -XX:+UseCMSCompactAtFullCollection：用于指定在执行完 Full GC 后对内存空间进行压缩整理，以此避免内存碎片的产生，由于内存压缩整理过程无法并发执行，所带来的问题就是停顿时间变得更长
• -XX:CMSFullGCsBeforecompaction：设置在执行多少次 Full GC 后对内存空间进行压缩整理
• -XX:ParallelCMSThreads：设置 CMS 的线程数量

• • CMS 默认启动的线程数是 (ParallelGCThreads+3)/4，ParallelGCThreads 是年轻代并行收集器的线程数
  • 收集线程占用的 CPU 资源多于25%，对用户程序影响可能较大；当 CPU 资源比较紧张时，受到 CMS 收集器线程的影响，应用程序的性能在垃圾回收阶段可能会非常糟糕

G1

G1 特点

G1是一款面向服务端应用的垃圾收集器，应用于新生代和老年代 、采用标记-整理算法、软实时、低延迟、可设定目标（最大 STW 停顿时间）的垃圾回收器，用于代替 CMS，适用于较大的堆（>4 ~ 6G），在 JDK9 之后默认使用 G1

G1 对比其他处理器的优点：

• 并发与并行：

• • 并行性：G1 在回收期间，可以有多个 GC 线程同时工作，有效利用多核计算能力，此时用户线程 STW
  • 并发性：G1 拥有与应用程序交替执行的能力，部分工作可以和应用程序同时执行，因此不会在整个回收阶段发生完全阻塞应用程序的情况
  • 其他的垃圾收集器使用内置的 JVM 线程执行 GC 的多线程操作，而 G1 GC 可以采用应用线程承担后台运行的 GC 工作，JVM 的 GC 线程处理速度慢时，系统会调用应用程序线程加速垃圾回收过程

• 分区算法：

• • 从分代上看，G1 属于分代型垃圾回收器，区分年轻代和老年代，年轻代依然有 Eden 区和 Survivor 区。从堆结构上看，新生代和老年代不再物理隔离，不用担心每个代内存是否足够，这种特性有利于程序长时间运行，分配大对象时不会因为无法找到连续内存空间而提前触发下一次 GC
  • 将整个堆划分成约 2048 个大小相同的独立 Region 块，每个 Region 块大小根据堆空间的实际大小而定，整体被控制在 1MB 到 32 MB之间且为 2 的 N 次幂，所有 Region 大小相同，在 JVM 生命周期内不会被改变。G1 把堆划分成多个大小相等的独立区域，使得每个小空间可以单独进行垃圾回收
  • 新的区域 Humongous ：本身属于老年代区，当出现了一个巨型对象超出了分区容量的一半，该对象就会进入到该区域。如果一个 H 区装不下一个巨型对象，那么 G1 会寻找连续的 H 分区来存储，为了能找到连续的 H 区，有时候不得不启动 Full GC
  • G1 不会对巨型对象进行拷贝，回收时被优先考虑，G1 会跟踪老年代所有 incoming 引用，这样老年代 incoming 引用为 0 的巨型对象就可以在新生代垃圾回收时处理掉
  • Region 结构图：

• 空间整合：

• • CMS：标记-清除算法、内存碎片、若干次 GC 后进行一次碎片整理
  • G1：整体来看是基于标记 - 整理算法实现的收集器，从局部（Region 之间）上来看是基于复制算法实现的，两种算法都可以避免内存碎片

• 可预测的停顿时间模型（软实时 soft real-time）：可以指定在 M 毫秒的时间片段内，消耗在 GC 上的时间不得超过 N 毫秒

• • 由于分块的原因，G1 可以只选取部分区域进行内存回收，这样缩小了回收的范围，对于全局停顿情况也能得到较好的控制
  • G1 跟踪各个 Region 里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间，通过过去回收的经验获得），在后台维护一个优先列表，每次根据允许的收集时间优先回收价值最大的 Region，保证了 G1 收集器在有限的时间内可以获取尽可能高的收集效率
  • 相比于 CMS GC，G1 未必能做到 CMS 在最好情况下的延时停顿，但是最差情况要好很多

G1 垃圾收集器的缺点：

• 相较于 CMS，G1 还不具备全方位、压倒性优势。比如在用户程序运行过程中，G1 无论是为了垃圾收集产生的内存占用还是程序运行时的额外执行负载都要比 CMS 要高
• 从经验上来说，在小内存应用上 CMS 的表现大概率会优于 G1，而 G1 在大内存应用上则发挥其优势，平衡点在 6-8GB 之间

应用场景：

• 面向服务端应用，针对具有大内存、多处理器的机器
• 需要低 GC 延迟，并具有大堆的应用程序提供解决方案

记忆集

记忆集 Remembered Set 在新生代 中，每个 Region 都有一个 Remembered Set，用来记录被哪些其他 Region 里的对象引用（谁引用了我就记录谁）

• 程序对 Reference 类型数据写操作时，产生一个 Write Barrier 暂时中断操作，检查该对象和 Reference 类型数据是否在不同的 Region（跨代引用），不同就将相关引用信息记录到 Reference 类型所属的 Region 的 Remembered Set 之中
• 进行内存回收时，在 GC 根节点的枚举范围中加入 Remembered Set 即可保证不对全堆扫描也不会有遗漏

垃圾收集器在新生代中建立了记忆集这样的数据结构，可以理解为它是一个抽象类，具体实现记忆集的三种方式：

• 字长精度
• 对象精度
• 卡精度(卡表)

卡表（Card Table）在老年代中，是一种对记忆集的具体实现，主要定义了记忆集的记录精度、与堆内存的映射关系等，卡表中的每一个元素都对应着一块特定大小的内存块，这个内存块称之为卡页（card page），当存在跨代引用时，会将卡页标记为 dirty，JVM 对于卡页的维护也是通过写屏障的方式

收集集合 CSet 代表每次 GC 暂停时回收的一系列目标分区，在任意一次收集暂停中，CSet 所有分区都会被释放，内部存活的对象都会被转移到分配的空闲分区中。年轻代收集 CSet 只容纳年轻代分区，而混合收集会通过启发式算法，在老年代候选回收分区中，筛选出回收收益最高的分区添加到 CSet 中

• CSet of Young Collection
• CSet of Mix Collection

工作原理

G1 中提供了三种垃圾回收模式：Young GC、Mixed GC 和 Full GC，在不同的条件下被触发

• 当堆内存使用达到一定值（默认 45%）时，开始老年代并发标记过程
• 标记完成马上开始混合回收过程

顺时针：Young GC → Young GC + Concurrent Mark → Mixed GC 顺序，进行垃圾回收

• Young GC ：发生在年轻代的 GC 算法，一般对象（除了巨型对象）都是在 eden region 中分配内存，当所有 eden region 被耗尽无法申请内存 时，就会触发一次 Young GC，G1 执行停止应用程序 的 STW，把活跃对象放入老年代，垃圾对象回收回收过程：

1. 1. 扫描根：根引用连同 RSet 记录的外部引用作为扫描存活对象的入口
   2. 更新 RSet：处理 dirty card queue 更新 RS，此后 RSet 准确的反映对象的引用关系

• • • dirty card queue：类似缓存，产生了引用先记录在这里，然后更新到 RSet
    • 作用：产生引用直接更新 RSet 需要线程同步开销很大，使用队列性能好

1. 1. 处理 RSet：识别被老年代对象指向的 Eden 中的对象，这些被指向的对象被认为是存活的对象，把需要回收的分区放入 Young CSet 中进行回收
   2. 复制对象：Eden 区内存段中存活的对象会被复制到 survivor 区，survivor 区内存段中存活的对象如果年龄未达阈值，年龄会加1，达到阀值会被会被复制到 old 区中空的内存分段，如果 survivor 空间不够，Eden 空间的部分数据会直接晋升到老年代空间
   3. 处理引用：处理 Soft，Weak，Phantom，JNI Weak 等引用，最终 Eden 空间的数据为空，GC 停止工作

• **Concurrent Mark **：

• • 初始标记：标记从根节点直接可达的对象，这个阶段是 STW 的，并且会触发一次年轻代 GC
  • 并发标记 (Concurrent Marking)：在整个堆中进行并发标记（应用程序并发执行），可能被 YoungGC 中断。会计算每个区域的对象活性，即区域中存活对象的比例，若区域中的所有对象都是垃圾，则这个区域会被立即回收（实时回收），给浮动垃圾准备出更多的空间，把需要收集的 Region 放入 CSet 当中
  • 最终标记：为了修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录，虚拟机将这段时间对象变化记录在线程的 Remembered Set Logs 里面，最终标记阶段需要把 Remembered Set Logs 的数据合并到 Remembered Set 中，这阶段需要停顿线程，但是可并行执行（防止漏标）
  • 筛选回收：并发清理阶段，首先对 CSet 中各个 Region 中的回收价值和成本进行排序，根据用户所期望的 GC 停顿时间来制定回收计划，也需要 STW

• Mixed GC ：当很多对象晋升到老年代时，为了避免堆内存被耗尽，虚拟机会触发一个混合的垃圾收集器，即 Mixed GC，除了回收整个 young region，还会回收一部分的 old region，过程同 YGC注意：是一部分老年代，而不是全部老年代 ，可以选择哪些老年代 region 收集，对垃圾回收的时间进行控制在 G1 中，Mixed GC 可以通过 -XX:InitiatingHeapOccupancyPercent 设置阈值
• Full GC：对象内存分配速度过快，Mixed GC 来不及回收，导致老年代被填满，就会触发一次 Full GC，G1 的 Full GC 算法就是单线程执行的垃圾回收，会导致异常长时间的暂停时间，需要进行不断的调优，尽可能的避免 Full GC产生 Full GC 的原因：

• • 晋升时没有足够的空间存放晋升的对象
  • 并发处理过程完成之前空间耗尽，浮动垃圾

调优

G1 的设计原则就是简化 JVM 性能调优，只需要简单的三步即可完成调优：

1. 开启 G1 垃圾收集器
2. 设置堆的最大内存
3. 设置最大的停顿时间（STW）

不断调优暂停时间指标：

• XX:MaxGCPauseMillis=x 可以设置启动应用程序暂停的时间，G1会根据这个参数选择 CSet 来满足响应时间的设置
• 设置到 100ms 或者 200ms 都可以（不同情况下会不一样），但设置成50ms就不太合理
• 暂停时间设置的太短，就会导致出现 G1 跟不上垃圾产生的速度，最终退化成 Full GC
• 对这个参数的调优是一个持续的过程，逐步调整到最佳状态

不要设置新生代和老年代的大小：

• 避免使用 -Xmn 或 -XX:NewRatio 等相关选项显式设置年轻代大小，G1 收集器在运行的时候会调整新生代和老年代的大小，从而达到我们为收集器设置的暂停时间目标
• 设置了新生代大小相当于放弃了 G1 的自动调优，我们只需要设置整个堆内存的大小，剩下的交给 G1 自己去分配各个代的大小

G1-重新整理

对堆的划分

以往对堆的划分：新生代和老生代，新生代又划分为 Eden 和 Survivor 区，Survivor 区又分为 from 区和 to 区。

G1将连续的Java堆空间划分为多个大小相等的独立区域 ，每个区域都可以成为Eden、Survivor等空间，且大小必须是2的N次幂（1M~32M）。这使得G1可以面向堆内存任何部分来组成回收集 进行回收，衡量标准不再是它属于哪个分代，而是哪块内存的垃圾的回收收益最大，这就是G1回收器的 Mixed GC (混合GC) 模式。

同时，G1还有一类Humongous区域，用来存储大对象（本身属于老生代），当对象大小超过一个Region容量一半时，对象即为大对象，大对象就会被存放到Humongous区中，当一个对象内存超过整个Humongous区时，将会被放在由多个连续的Humongous组成的区域中。

工作流程

新生代回收

回收对象：Eden 区和 Survivor 区

触发条件：Eden 区被分配的对象填满

过程（STW）：

1. 根扫描：停止应用线程，从 GC Roots（栈引用、静态变量等）开始扫描。
2. 更新记忆集：处理脏卡片，更新 RSet，以了解哪些老年代对象引用了当前回收集中的对象。
3. 对象拷贝：将 Eden 区和 From Survivor 区中存活的对象，拷贝到 To Survivor 区（复制算法）。如果对象年龄达到阈值或 To 区空间不足，直接晋升到老年代 Region。

G1对比CMS

• G1从整体上来看是 标记-整理 算法，但从局部（两个Region之间）是复制算法。而CMS是 标记-清除算法 所以说，G1不会产生内存碎片，而CMS会产生内存碎片
• CMS使用了 写后屏障来维护卡表，而G1不仅使用了写后屏障来维护卡表，还是用了 写前屏障来跟踪并发时的指针变化情况（为了实现原始快照）。
• CMS对Java堆内存使用的是传统的 新生代和老年代划分方法，而G1使用的全新的划分方法。
• CMS收集器只收集老年代，可以配合新生代的Serial和ParNew收集器一起使用。G1收集器收集范围是老年代和新生代。不需要结合其他收集器使用
• CMS使用 增量更新 解决并发标记下出现的错误标记问题，而G1使用原始快照解决

ZGC

ZGC 收集器是一个可伸缩的、低延迟的垃圾收集器，基于 Region 内存布局的，不设分代，使用了读屏障、染色指针和内存多重映射等技术来实现可并发的标记压缩算法

• 在 CMS 和 G1 中都用到了写屏障，而 ZGC 用到了读屏障
• 染色指针：直接将少量额外的信息存储在指针上的技术，从 64 位的指针中拿高 4 位来标识对象此时的状态

• • 染色指针可以使某个 Region 的存活对象被移走之后，这个 Region 立即就能够被释放和重用
  • 可以直接从指针中看到引用对象的三色标记状态（Marked0、Marked1）、是否进入了重分配集、是否被移动过（Remapped）、是否只能通过 finalize() 方法才能被访问到（Finalizable）
  • 可以大幅减少在垃圾收集过程中内存屏障的使用数量，写屏障的目的通常是为了记录对象引用的变动情况，如果将这些信息直接维护在指针中，显然就可以省去一些专门的记录操作
  • 可以作为一种可扩展的存储结构用来记录更多与对象标记、重定位过程相关的数据

• 内存多重映射：多个虚拟地址指向同一个物理地址

可并发的标记压缩算法：染色指针标识对象是否被标记或移动，读屏障保证在每次应用程序或 GC 程序访问对象时先根据染色指针的标识判断是否被移动，如果被移动就根据转发表访问新的移动对象，并更新引用，不会像 G1 一样必须等待垃圾回收完成才能访问

ZGC 目标：

• 停顿时间不会超过 10ms
• 停顿时间不会随着堆的增大而增大（不管多大的堆都能保持在 10ms 以下）
• 可支持几百 M，甚至几 T 的堆大小（最大支持4T）

ZGC 的工作过程可以分为 4 个阶段：

• 并发标记（Concurrent Mark）： 遍历对象图做可达性分析的阶段，也要经过初始标记和最终标记，需要短暂停顿
• 并发预备重分配（Concurrent Prepare for Relocate）：根据特定的查询条件统计得出本次收集过程要清理哪些 Region，将这些 Region 组成重分配集（Relocation Set）
• 并发重分配（Concurrent Relocate）： 重分配是 ZGC 执行过程中的核心阶段，这个过程要把重分配集中的存活对象复制到新的 Region 上，并为重分配集中的每个 Region 维护一个转发表（Forward Table），记录从旧地址到新地址的转向关系
• 并发重映射（Concurrent Remap）：修正整个堆中指向重分配集中旧对象的所有引用，ZGC 的并发映射并不是一个必须要立即完成的任务，ZGC 很巧妙地把并发重映射阶段要做的工作，合并到下一次垃圾收集循环中的并发标记阶段里去完成，因为都是要遍历所有对象，这样合并节省了一次遍历的开销

ZGC 几乎在所有地方并发执行的，除了初始标记的是 STW 的，但这部分的实际时间是非常少的，所以响应速度快，在尽可能对吞吐量影响不大的前提下，实现在任意堆内存大小下都可以把垃圾收集的停顿时间限制在十毫秒以内的低延迟

优点：高吞吐量、低延迟

缺点：浮动垃圾，当 ZGC 准备要对一个很大的堆做一次完整的并发收集，其全过程要持续十分钟以上，由于应用的对象分配速率很高，将创造大量的新对象产生浮动垃圾

垃圾回收失败

指垃圾回收器无法释放足够的内存来满足新的对象分配请求，最终导致程序无法继续运行。

原因

1. 内存耗尽（OOM）：

• • 堆内存耗尽 ：内存泄漏，无法释放一些不在使用的对象，导致内存一直被这些对象占用经典场景：静态集合类占有内存但后续不再使用、资源未关闭（连接、流等）、ThreadLocal调用后没有进行清理（Thread Local的value是强引用，需要手动回收）、变量作用域不合理（局部变量被提升到过高的作用域，其生命周期过长，导致内存占用）
  • 元空间/方法区内存耗尽 ：类加载器泄漏、加载了过多的类
  • 堆外内存耗尽：堆外内存使用后没有被正确释放

1. 并发模式失败：CMS、G1这类并发垃圾收集器特殊情况导致的失败

原因：老生代空间预留不足，对象分配/提升速度过快，超过并发收集器回收速度

1. 1. 并发收集器（如CMS）正在并发地清理老年代（执行CMS的并发清理阶段）。
   2. 应用线程还在运行并产生新的垃圾，同时可能提升对象到老年代。
   3. 老年代的空间不足了，需要立即进行GC，但并发收集器还没清理完，来不及响应。

1. 晋升失败Minor GC后，有一批对象需要晋升到老年代，老年代没有足够的连续空间容纳晋升对象，JVM被迫触发Full GC，但Full GC后老年代空间仍然不足，导致OOM

总结

Serial GC、Parallel GC、Concurrent Mark Sweep GC 这三个 GC 不同：

• 最小化地使用内存和并行开销，选 Serial GC
• 最大化应用程序的吞吐量，选 Parallel GC
• 最小化 GC 的中断或停顿时间，选 CMS GC

内存泄漏

泄露溢出

内存泄漏 ：是指程序中已动态分配的堆内存由于某种原因程序未释放或无法释放，造成系统内存的浪费，导致程序运行速度减慢甚至系统崩溃等严重后果

可达性分析算法来判断对象是否是不再使用的对象，本质都是判断一个对象是否还被引用。由于代码的实现不同就会出现很多种内存泄漏问题，让 JVM 误以为此对象还在引用中，无法回收，造成内存泄漏

内存溢出指的是申请内存时，没有足够的内存可以使用

内存泄漏和内存溢出的关系：内存泄漏的越来越多，最终会导致内存溢出

几种情况

静态集合

静态集合类的生命周期与 JVM 程序一致，则容器中的对象在程序结束之前将不能被释放，从而造成内存泄漏。原因是长生命周期的对象持有短生命周期对象的引用，尽管短生命周期的对象不再使用，但是因为长生命周期对象持有它的引用而导致不能被回收

单例模式

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

内部类

内部类持有外部类的情况，如果一个外部类的实例对象调用方法返回了一个内部类的实例对象，即使那个外部类实例对象不再被使用，但由于内部类持有外部类的实例对象，这个外部类对象也不会被回收，造成内存泄漏

连接相关

数据库连接、网络连接和 IO 连接等，当不再使用时，需要显式调用 close 方法来释放与连接，垃圾回收器才会回收对应的对象，否则将会造成大量的对象无法被回收，从而引起内存泄漏

不合理域

变量不合理的作用域，一个变量的定义的作用范围大于其使用范围，很有可能会造成内存泄漏；如果没有及时地把对象设置为 null，也有可能导致内存泄漏的发生

改变哈希

当一个对象被存储进 HashSet 集合中以后，就不能修改这个对象中的那些参与计算哈希值的字段，否则对象修改后的哈希值与最初存储进 HashSet 集合中时的哈希值不同，这种情况下使用该对象的当前引用作为的参数去 HashSet 集合中检索对象返回 false，导致无法从 HashSet 集合中单独删除当前对象，造成内存泄漏

缓存泄露

内存泄漏的一个常见来源是缓存，一旦把对象引用放入到缓存中，就会很容易被遗忘

使用 WeakHashMap 代表缓存，当除了自身有对 key 的引用外没有其他引用，map 会自动丢弃此值