垃圾回收算法（GC Algorithms）
JVM 根据对象生命周期特性（分代假设）采用不同的回收算法，核心算法包括：
标记-清除（Mark-Sweep）
此算法执行分两阶段。第一阶段从引用根节点开始标记所有被引用的对象，第二阶段遍历整个堆，把未标记的对象清除。
流程：标记所有存活对象 → 清除未标记对象。
优点：简单、无对象移动开销。
缺点：内存碎片化、效率较低（需遍历两次堆）。
复制算法（Copying）
此算法把内存空间划为两个相等的区域，每次只使用其中一个区域。垃圾回收时，遍历当前使用区域，把正在使用中的对象复制到另外一个区域中。此算法每次只处理正在使用中的对象，因此复制成本比较小， 同时复制过去以后还能进行相应的内存整理，不会出现"碎片"问题。当然，此算法的缺点也是很明显的，就是需要两倍内存空间。
流程：将存活对象复制到另一块内存区域 → 清空原区域。
优点：无碎片、效率高（适用于存活率低的对象，如新生代）。
缺点：内存利用率低（需预留一半空间）。
标记-整理（Mark-Compact）
此算法结合了"标记-清除"和"复制"两个算法的优点。也是分两阶段，第一阶段从根节点开始标记所有被引用对象，第二阶段遍历整个堆，把清除未标记对象并且把存活对象"压缩"到堆的其中一块，按顺序排放。此算法避免了"标记-清除"的碎片问题，同时也避免了"复制"算法的空间问题。
流程：标记存活对象 → 移动对象到内存一端 → 清理边界外内存。
优点：无碎片、内存利用率高。
缺点：对象移动开销大（适用于老年代）。
分代收集（Generational Collection）
核心思想：根据对象存活时间划分内存区域（新生代、老年代）。
新生代：存活率低 → 使用复制算法（如 Serial、ParNew）。
老年代：存活率高 → 使用标记-清除或标记-整理算法（如 CMS、G1）。
可达性算法（Reachability Analysis）
可达性算法（Reachability Analysis）是 JVM 垃圾回收的核心机制，用于判断对象是否存活。其核心思想是：从一组根对象（GC Roots）出发，遍历所有引用链，未被引用的对象视为可回收垃圾。以下是其详细原理、流程和应用场景：
可达性算法的基本流程
1.确定 GC Roots
JVM 枚举所有根对象（如栈帧中的局部变量、静态变量等），作为遍历起点。
2.遍历引用链
从 GC Roots 出发，递归遍历所有直接或间接引用的对象，形成对象图（Object Graph）。
3.标记存活对象
所有被遍历到的对象标记为存活（如使用三色标记法中的黑色或灰色状态）。
4.回收不可达对象
未被遍历到的对象（白色对象）视为垃圾，由具体 GC 算法回收（如标记-清除、复制等）。
GC Roots 的具体类型
以下对象被定义为 GC Roots，不会被回收：
虚拟机栈中的引用
当前执行方法的局部变量、方法参数（如 public void foo(Object param)）。
当前线程的调用栈中所有方法的局部变量。
本地方法栈中的引用
JNI（Java Native Interface）方法中的对象引用（如通过 JNIEnv 调用的对象）。
方法区的静态变量和常量
类的静态变量（static 修饰）。
字符串常量池中的引用（如 String s = "abc"）。
同步锁持有的对象
通过 synchronized 关键字锁定的对象（如 synchronized(obj) 中的 obj）。
JVM 内部对象
系统类加载器（ClassLoader）加载的类。
异常对象（如 OutOfMemoryError）、线程对象等。
跨代引用记录对象
卡表（Card Table）中记录的老年代对新生代的引用（需特殊处理）。
引用类型对可达性的影响
| 引用类型 | 强引用（Strong） | 软引用（Soft） | 弱引用（Weak） | 虚引用（Phantom） |
|---|---|---|---|---|
| 定义 | 默认引用（Object obj = new Object()） | 内存不足时回收（SoftReference） | 下次 GC 必回收（WeakReference） | 仅用于跟踪对象回收（PhantomReference） |
| 可达性影响 | 强可达 | 软可达 | 弱可达 | 不可达 |
| 回收条件 | 不可达时回收 | 内存不足时回收 | 无论内存是否充足均回收 | 对象回收后入队通知 |
示例：
java
Object strongRef = new Object(); // 强引用
SoftReference<Object> softRef = new SoftReference<>(new Object());
WeakReference<Object> weakRef = new WeakReference<>(new Object());
PhantomReference<Object> phantomRef = new PhantomReference<>(new Object(), new ReferenceQueue<>());三色标记（Tri-color Marking）
定义
用三种颜色抽象对象的状态：
白色（White）
初始状态：对象未被访问（未标记）。
最终回收：标记完成后仍为白色的对象视为可回收垃圾。
灰色（Gray）
中间状态：对象被标记为存活，但其子引用（成员变量、数组元素等）尚未被遍历。
黑色（Black）
最终存活状态：对象被标记为存活，且所有子引用已被遍历完成。
标记流程（基本步骤）
初始阶段
所有对象设为白色。
将 GC Roots 直接引用的对象标记为灰色（放入灰色队列）。
标记阶段（并发）
从灰色队列中取出对象：
---遍历该对象的所有子引用，将子引用指向的白色对象标记为灰色。
---将当前对象标记为黑色。
重复上述过程，直到灰色队列为空。
最终阶段
所有存活对象应为黑色，白色对象视为垃圾。
并发标记的两种问题
因用户线程与 GC 线程并发运行，对象引用可能发生变化，导致两种风险：
漏标（对象丢失）
场景：
黑色对象（已标记完成）被用户线程写入了一个新的白色对象引用。
用户线程删除了灰色对象到某个白色对象的引用。
结果：
白色对象未被标记为存活，导致被错误回收。
例：
java
初始：黑(A) → 灰(B) → 白(C) → 白(D)
B 即将处理，但此时用户线程执行：
1. A.field = D // 黑对象引用了白对象
2. B.field = null // 断开灰对象到C的引用
最终：C未标记（白色），D未标记（白色），会被误回收。解决
- 增量更新（Incremental Update）
原理：记录新插入的引用，重新标记。
实现：当用户线程将黑色对象插入对白色对象的引用时，通过写屏障（Write Barrier） 将黑色对象重新标记为灰色。
示例 GC：CMS（Concurrent Mark-Sweep）。
2. 原始快照（SATB, Snapshot At The Beginning）
原理：基于标记开始时存在的对象引用关系快照（即假设这些对象是存活的）。
实现：当用户线程修改引用关系（如删除一个引用），通过写屏障将旧引用的目标对象标记为灰色。
示例 GC：G1、ZGC、Shenandoah。
错标（浮动垃圾）
场景：
对象实际已死亡，但在标记阶段被标记为存活。
解决：
可容忍：仅导致少量内存未及时释放，下次 GC 可清理。
OopMap（Ordinary Object Pointer Map）
OopMap 记录了栈上本地变量到堆上对象的引用关系。其作用是：垃圾收集时，收集线程会对栈上的内存进行扫描，看看哪些位置存储了 Reference 类型。如果发现某个位置确实存的是 Reference 类型，就意味着它所引用的对象这一次不能被回收。但问题是，栈上的本地变量表里面只有一部分数据是 Reference 类型的（它们是我们所需要的），那些非 Reference 类型的数据对我们而言毫无用处，但我们还是不得不对整个栈全部扫描一遍，这是对时间和资源的一种浪费。
一个很自然的想法是，能不能用空间换时间，在某个时候把栈上代表引用的位置全部记录下来，这样到真正 gc 的时候就可以直接读取，而不用再一点一点的扫描了。事实上，大部分主流的虚拟机也正是这么做的，比如 HotSpot ，它使用一种叫做 OopMap 的数据结构来记录这类信息。
我们知道，一个线程意味着一个栈，一个栈由多个栈帧组成，一个栈帧对应着一个方法，一个方法里面可能有多个安全点。 gc 发生时，程序首先运行到最近的一个安全点停下来，然后更新自己的 OopMap ，记下栈上哪些位置代表着引用。枚举根节点时，递归遍历每个栈帧的 OopMap ，通过栈中记录的被引用对象的内存地址，即可找到这些对象（ GC Roots ）。
OopMap（Ordinary Object Pointer Map）是 JVM 用于快速定位 GC Roots 的关键数据结构，通过记录栈帧和寄存器中的对象引用位置，显著减少垃圾回收时的停顿时间（Stop-The-World, STW）。以下是其生成时机及作用机制的详细解析：
OopMap 的生成时机
OopMap 的生成与 JIT 编译器 和 安全点（Safe Point） 密切相关，主要发生在以下场景：
方法编译时（JIT 阶段）
即时编译（JIT）：
当方法被 JIT 编译器编译为本地机器码时，编译器会分析方法的栈帧布局，并生成对应的 OopMap。
记录内容：
栈帧中哪些位置（偏移量）存储了对象引用（Oop，Ordinary Object Pointer）。如：局部变量表、方法参数、this 指针等。
示例：
若方法的局部变量表第 3 个槽位是 Object obj，则 OopMap 会记录该槽位的偏移量。
安全点（Safe Point）
安全点触发：当 JVM 需要执行 GC、代码反优化等操作时，所有用户线程必须暂停在安全点。
安全点位置：通常插入在方法调用、循环回边（如 for 循环）、异常抛出等位置（避免长时间不进入安全点）。
OopMap 更新：在安全点处，JVM 会生成或更新当前线程的 OopMap，确保准确记录此时栈帧和寄存器中的引用。
GC 仅是触发安全点的一种场景，其他操作（如偏向锁撤销）也会触发安全点。
并非所有 OopMap 都在 GC 前生成，但 GC 前必须依赖安全点更新 OopMap。
特定指令插入
显式生成指令：JIT 编译器会在生成的机器码中插入特殊指令（如 test 指令），用于检查是否需要进入安全点并生成 OopMap。
OopMap 如何协助 JVM 获取 GC Roots
GC Roots 是垃圾回收的起点，包括栈帧中的局部变量、静态变量、JNI 引用等。OopMap 的作用是快速枚举这些根引用，避免全栈扫描。
快速定位引用位置
直接映射：OopMap 明确记录了栈帧中哪些位置存储了对象引用（如局部变量、方法参数）。
寄存器记录：部分引用可能存储在寄存器中（如 this 指针），OopMap 也会记录这些寄存器的名称。
结合安全点减少 STW 时间
暂停线程：当 GC 触发时，所有线程需快速暂停在安全点。
遍历 OopMap：GC 线程直接读取各线程的 OopMap，遍历记录的引用位置，收集所有 GC Roots。
无需全栈扫描：避免逐字节检查整个栈内存，极大缩短暂停时间。
与卡表（Card Table）协作
维护跨代引用：卡表用于记录老年代到新生代的引用，OopMap 帮助快速定位这些引用所在的栈或寄存器位置。
写屏障支持：当用户线程修改对象引用时，写屏障会更新卡表，而 OopMap 确保这些修改在 GC 时被正确识别。
OopMap 与 GC 流程的协作
以 Young GC 为例，流程如下：
1.触发 GC：新生代空间不足，需回收。
2.进入安全点：所有用户线程暂停，生成 OopMap。
3.枚举 GC Roots：
---根据 OopMap 遍历所有线程的栈帧和寄存器，收集指向新生代的引用（如局部变量 obj）。
---结合卡表，找到老年代中指向新生代的对象。
4.标记存活对象：从 GC Roots 出发，标记所有可达对象。
5.恢复线程：完成 GC 后，线程继续执行。