【JVM深度解析】第04篇：垃圾回收算法与实现原理

摘要垃圾回收Garbage CollectionGC是 JVM 自动内存管理的核心机制将开发者从手动管理内存的繁琐中解放出来但也带来了性能开销。本文深入解析 GC 的完整技术体系从对象存活性判断引用计数法 vs 可达性分析法、四种引用类型强/软/弱/虚到三大基础算法标记-清除、标记-整理、复制再到分代收集理论与 HotSpot 中的跨代引用处理机制记忆集/卡表/写屏障。重点剖析 Stop-The-World 的本质原理与 SafePoint/SafeRegion 机制最终通过与实际 GC 算法的对应关系建立从理论到实践的完整映射。引言GC 是 Java 最被讨论却最少被理解的话题之一。开发者们常常满足于GC 会自动管内存的粗浅认知直到线上 Full GC 频繁、服务停顿数秒、应用响应超时的那一刻才意识到深入理解 GC 的必要性。但 GC 并不神秘。它本质上就是在回答两个问题哪些对象是垃圾对象存活判断怎么回收这些垃圾回收算法理解了这两个问题GC 的所有行为都变得清晰可预期。一、判断对象已死垃圾的认定1.1 引用计数法Reference Counting原理为每个对象维护一个引用计数器每有一个引用指向该对象则加 1引用失效则减 1计数为 0 的对象即可回收。Object A ──→ 计数器: 2 被 B 和 C 引用 Object B ──→ 计数器: 1 被 A 引用 Object C ──→ 计数器: 0 ← 可以回收 ✅优点实现简单回收即时计数归零立即回收无需 GC 扫描致命缺点——循环引用// 循环引用导致内存泄漏classNode{Nodenext;}NodeanewNode();NodebnewNode();a.nextb;// b 的引用计数 1b.nexta;// a 的引用计数 1anull;// 局部变量 a 不再引用但对象 A 的计数仍为 1b.next 指着它bnull;// 局部变量 b 不再引用但对象 B 的计数仍为 1a.next 指着它// A 和 B 的引用计数都为 1永远不会被回收// 这就是循环引用导致的内存泄漏循环引用示意 ┌──────────────────┐ ↓ │ 对象 A (计数1) ──→ 对象 B (计数1) │ └──→ 对象 A形成循环 外部已无引用但两者计数都不为0无法回收 ❌现实应用Python、PHP、Swift 等使用引用计数但都配备了循环引用检测机制。JVM 不使用引用计数法主流 JVM 均使用可达性分析。1.2 可达性分析法Reachability Analysis原理从一组称为GC Roots的根对象出发沿着引用链向下遍历。能被 GC Roots 直接或间接引用到的对象为可达存活无法到达的对象即为垃圾。GC Roots根节点 ├── 当前所有线程的虚拟机栈中的对象引用局部变量、方法参数 ├── 方法区中静态变量引用的对象 ├── 方法区中常量引用的对象如字符串常量池中的引用 ├── 本地方法栈中 JNI 引用的对象 ├── JVM 内部引用基本类型对应的 Class 对象、常驻异常对象如 NPE、OOM ├── 被 synchronized 持有的对象 └── JMXBean、JVMTI 中的回调注册对象等 GC Root 1 GC Root 2 GC Root 3 │ │ │ ▼ ▼ ▼ 对象 A 对象 C ──→ 对象 E │ │ ▼ ▼ 对象 B 对象 D 对象 F ──→ 对象 G 没有 GC Root 可到达F 和 G 都是垃圾可达性分析解决了循环引用问题即使 A ↔ B 互相引用但如果从 GC Roots 出发无法到达 A 和 B 它们依然被判定为垃圾可以回收。✅1.3 对象的两次死亡机会即使被可达性分析判定为不可达对象还有一次复活机会第一次标记不可达 │ ▼ 是否覆盖了 finalize() 方法 │ │ 否 是 │ │ ▼ ▼ 直接回收 被放入 F-Queue JVM 低优先级线程执行 finalize() 如果在 finalize() 中重新建立引用 ───────────────────────────────── Object.SAVE_HOOK this; // 自救 第二次标记时检查仍不可达→ 回收 如果可达→ 从回收集合中移除对象复活 ✅ ⚠️ 注意finalize() 每个对象只会被调用一次⚠️ 建议finalize()方法不可预测、难以调试、已被官方标记为弃用DeprecatedJava 9。尽量不要使用。需要清理资源时使用try-with-resources或显式的close()方法。二、四种引用类型JDK 1.2 引入了四种引用强度允许开发者精细控制对象的 GC 行为引用强度排序强引用 软引用 弱引用 虚引用 GC 压力 强引用 ─────────────────────────────── 永不回收除非引用断开 软引用 ─────────────────────────────── 内存不足时回收 弱引用 ─────────────────────────────── 下次 GC 必定回收 虚引用 ─────────────────────────────── 随时可回收主要用于跟踪回收动作2.1 强引用Strong Reference// 普通的引用赋值就是强引用ObjectobjnewObject();// obj 是强引用// 只要 obj 不为 null对象永远不会被 GC 回收// 即使 OOMJVM 也不会回收强引用对象objnull;// 断开引用对象才能被 GC2.2 软引用Soft Reference// 内存充足时保留内存不足时回收适合做缓存SoftReferencebyte[]softRefnewSoftReference(newbyte[1024*1024]);// 访问时需要判空byte[]datasoftRef.get();if(datanull){// 已被 GC需要重新加载dataloadData();softRefnewSoftReference(data);}// 典型应用图片缓存MapString,SoftReferenceImageimageCachenewHashMap();2.3 弱引用Weak Reference// 无论内存是否充足下次 GC 必定被回收WeakReferenceObjectweakRefnewWeakReference(newObject());// GC 后 weakRef.get() 返回 null// 典型应用1ThreadLocal 的 ThreadLocalMap// key 是 WeakReferenceThreadLocal防止 ThreadLocal 对象泄漏// 但 value 是强引用value 泄漏仍需手动 remove()// 典型应用2WeakHashMapkey 为弱引用key 被 GC 后 entry 自动清除WeakHashMapObject,StringweakMapnewWeakHashMap();2.4 虚引用Phantom Reference// 无法通过虚引用获取对象仅用于跟踪对象被回收的动作// 必须配合 ReferenceQueue 使用ReferenceQueueObjectqueuenewReferenceQueue();PhantomReferenceObjectphantomRefnewPhantomReference(newObject(),queue);// phantomRef.get() 永远返回 null// 当对象被 GC 时PhantomReference 会被加入 queue// 监控线程可以处理 queue 来执行清理操作// 典型应用NIO 的 DirectByteBuffer 堆外内存回收JDK9 Cleaner机制三、三大基础回收算法所有 GC 实现都基于以下三种基础算法的组合3.1 标记-清除算法Mark-Sweep步骤标记阶段从 GC Roots 出发标记所有可达对象清除阶段遍历堆内存未被标记的对象占用的空间置为空闲标记前 ┌──────────────────────────────────────────────────────────┐ │ [存活A] [垃圾B] [存活C] [垃圾D] [垃圾E] [存活F] [垃圾G] │ └──────────────────────────────────────────────────────────┘ 标记后✓ 表示存活 ┌──────────────────────────────────────────────────────────┐ │ [✓ A ] [垃圾B] [✓ C ] [垃圾D] [垃圾E] [✓ F ] [垃圾G] │ └──────────────────────────────────────────────────────────┘ 清除后 ┌──────────────────────────────────────────────────────────┐ │ [存活A] [空 ] [存活C] [空 ] [空 ] [存活F] [空 ] │ └──────────────────────────────────────────────────────────┘ ↑ 内存碎片优点实现简单不需要移动对象无需更新引用缺点内存碎片清除后内存不连续大对象分配困难效率随碎片增加而降低分配时需要遍历空闲列表需要 Stop-The-World标记阶段需要一致的内存快照应用场景CMS 的老年代回收3.2 标记-整理算法Mark-Compact步骤标记阶段同标记-清除标记存活对象整理阶段将所有存活对象向一端移动然后清除边界外的内存标记前 ┌──────────────────────────────────────────────────────────┐ │ [存活A] [垃圾B] [存活C] [垃圾D] [垃圾E] [存活F] [垃圾G] │ └──────────────────────────────────────────────────────────┘ 整理后存活对象移动到左侧消除碎片 ┌──────────────────────────────────────────────────────────┐ │ [存活A] [存活C] [存活F] [────────── 连续空闲内存 ─────────] │ └──────────────────────────────────────────────────────────┘ ↑ 指针碰撞分配区域高效优点无内存碎片可用指针碰撞快速分配内存空间利用率高缺点移动对象代价高需要更新所有指向被移动对象的引用Stop-The-World 时间更长需要移动对象并更新引用应用场景Serial Old、Parallel Old 的老年代回收G1 的 Mixed GC3.3 复制算法Copying步骤将内存分为两个等大的半区From 和 To每次只使用 From 区GC 时将 From 区的存活对象全部复制到 To 区紧凑排列清空 From 区交换 From/To 角色GC 前From 区 ┌──────────────────────────────────┐ ┌──────────────────────────────────┐ │ [存活A][垃圾B][存活C][垃圾D][垃圾E]│ │ 空闲To 区 │ └──────────────────────────────────┘ └──────────────────────────────────┘ From 区使用中 To 区 GC 后复制到 To 区 ┌──────────────────────────────────┐ ┌──────────────────────────────────┐ │ 清空新的 To 区 │ │ [存活A][存活C] ← 指针碰撞分配区域 │ └──────────────────────────────────┘ └──────────────────────────────────┘ 原 From 区 原 To 区新 From 区优点无内存碎片复制后紧凑排列分配效率高指针碰撞GC 效率高只遍历存活对象存活对象少时速度快缺点内存利用率只有 50%一半空间始终空闲存活对象多时复制代价高不适合老年代应用场景年轻代 GC存活率低复制量少3.4 三种算法对比对比维度标记-清除标记-整理复制内存碎片有无无内存利用率高高50%GC 停顿时间中等较长较短存活少时适用场景老年代存活多移动代价高老年代高吞吐优先年轻代存活少主要用例CMS 老年代Serial/Parallel Old年轻代所有收集器四、分代收集理论4.1 两个假说支撑分代设计现代 GC 的分代收集理论基于两个被大量实践验证的假说弱分代假说Weak Generational Hypothesis绝大多数对象都是朝生夕灭的——大部分对象在创建后很快就变成垃圾。强分代假说Strong Generational Hypothesis熬过越多次 GC 的对象越难以消亡。基于这两个假说JVM 将堆分为年轻代Young Generation和老年代Old Generation针对不同的对象特征使用最适合的算法年轻代对象存活率极低一次 Minor GC 通常回收 90% → 使用复制算法只需复制少量存活对象高效 → 频繁 GC但每次 GC 速度快 老年代对象存活率高都是熬过来的长寿对象 → 使用标记-清除 或 标记-整理不适合复制存活对象太多 → 较少 GC但每次 GC 代价较大4.2 跨代引用问题分代 GC 面临一个棘手问题老年代对象可能引用年轻代对象。Minor GC 只扫描年轻代但如果老年代引用了年轻代对象这些对象不应该被回收——可这要怎么知道错误做法每次 Minor GC 都扫描老年代相当于 Full GC失去了分代的意义正确做法记忆集Remembered Set 卡表Card Table卡表Card Table原理 堆内存 ┌────────────────────────────────────────────────────────────────┐ │ 老年代 │ │ [卡页0][卡页1][卡页2][卡页3][卡页4][卡页5][卡页6][卡页7]... │ │ 512B 512B 512B 脏 512B 512B 脏 512B │ └────────────────────────────────────────────────────────────────┘ 卡表Card Table 每个卡页对应一个字节脏位标记 [ 0 ][ 0 ][ 0 ][ 1 ][ 0 ][ 0 ][ 1 ][ 0 ]... ↑ ↑ 卡页3是脏的 卡页6是脏的 含有指向年轻代的引用 含有指向年轻代的引用 Minor GC 时 只需扫描脏卡页而非整个老年代找到跨代引用 将这些跨代引用加入 GC Roots确保被引用的年轻代对象不被回收。写屏障Write Barrier当对象引用关系发生变化赋值语句obj.field newRef时JVM 通过写屏障代码将对应的卡页标记为脏// 普通赋值 obj.field newRef; // JIT 编译后含写屏障相当于 obj.field newRef; if (对象 obj 在老年代 newRef 在年轻代) { CARD_TABLE[addr(obj) 9] DIRTY; // 9 除以512卡页大小 }五、Stop-The-World 与 SafePoint5.1 为什么需要 Stop-The-WorldGC 在标记对象存活状态时需要一个一致的内存快照。如果标记过程中对象引用关系在不断变化就可能出现危险场景没有 STW T1: GC 开始标记发现 对象A 可达 T2: 用户线程执行唯一引用 A 的变量 nullA 变成垃圾了 T3: GC 继续A 被错误地标记为存活对象游离即浮动垃圾 或者反向危险 T1: GC 已经扫描过 对象B标记为不可达垃圾 T2: 用户线程执行新建了一个到 B 的引用B 复活了 T3: GC 回收了 B被错误回收产生悬空指针Stop-The-WorldSTW通过暂停所有用户线程来保证内存快照的一致性避免上述问题。5.2 SafePoint安全点JVM 不能在任意位置暂停线程而是让线程运行到**安全点SafePoint**后才能停下来。安全点是代码中的特定位置在这些位置上对象引用关系已知通过 OopMap 记录了哪些位置有对象引用线程可以安全地被挂起安全点的设置位置- 方法调用点方法返回之前 - 循环的末尾循环体回跳之前防止超长循环不到达安全点 - 异常处理代码 - 可能发生 GC 的位置STW 的执行流程GC 触发 │ ▼ JVM 设置标志位需要 GC │ ▼ 各线程检查标志位在安全点检查 │ ▼ 线程到达最近的安全点后挂起 │ ▼ 所有线程都到达安全点全部停止 │ ▼ GC 执行此时内存状态固定 │ ▼ GC 完成唤醒所有线程继续执行5.3 SafeRegion安全区域如果线程处于 Sleep 或 Blocked 状态如等待 I/O它可能长时间无法到达安全点。安全区域Safe Region一段代码区域在这段代码中引用关系不会发生变化。JVM 可以在安全区域内任意位置暂停线程。// 线程正在执行 I/O 等待被标记进入安全区域Thread.sleep(1000);// 在 sleep 期间不会改变对象引用关系// 线程进入安全区域后可以随时被 GC 暂停六、GC 的性能核心指标6.1 吞吐量 vs 停顿时间GC 设计面临根本性的权衡高吞吐量 低停顿时间 ────────────────────────────────────────────────────── 用户代码运行时间 / 总运行时间 最大 GC 停顿时间 ████ GC ████████ 用户代码 ████ GC ████ ─ STW 时间 ─ 吞吐量 用户运行时间 / (用户时间 GC时间) 停顿时间 max(单次GC停顿) 特点GC 可以耗时较长 特点GC 单次停顿要短 但整体运行用户代码的比例高 即使总 GC 耗时更多 适合后台批处理、科学计算 适合交互式应用、在线服务 代表Parallel GCJDK8 默认 代表ZGC、Shenandoah6.2 GC 的三大评估指标指标定义优化方向吞吐量用户代码时间 / (用户时间 GC时间)提高适合批处理场景停顿时间单次 GC 导致的最长 STW 时间降低适合在线服务内存占用GC 本身需要的额外内存降低适合内存紧张场景GC 调优的核心矛盾吞吐量与停顿时间往往是对立的——降低停顿时间增加 GC 频率会降低吞吐量提高吞吐量减少 GC 频率单次 GC 处理更多会增加单次停顿时间。选择 GC 收集器和调优参数本质上是在这两者之间找到适合业务需求的平衡点。七、GC 算法与收集器的对应关系GC 收集器年轻代算法老年代算法特性Serial Serial Old复制标记-整理单线程停顿长简单稳定ParNew CMS复制标记-清除并发低停顿有碎片Parallel Scavenge Parallel Old复制标记-整理多线程高吞吐JDK8默认G1复制Region间标记-整理Region内可预测停顿平衡ZGC着色指针复制着色指针复制超低停顿10msShenandoah复制并发整理Brooks指针并发整理低停顿八、总结GC 的本质是两步判定垃圾可达性分析回收垃圾三大算法。可达性分析从 GC Roots 出发不可达 垃圾彻底解决了引用计数法的循环引用问题三大算法标记-清除简单但碎片、标记-整理无碎片但移动开销大、复制高效但内存减半——现代 GC 都是三者的组合分代收集基于弱分代假说年轻代用复制算法老年代用标记-整理/标记-清除通过卡表写屏障处理跨代引用STW 与安全点GC 需要暂停用户线程STW来保证内存快照一致性线程在安全点处停止进入安全区域的线程可随时暂停核心权衡吞吐量 vs 停顿时间没有银弹只有适合业务场景的最优解下一篇预告有了算法基础我们来看算法的载体——具体的垃圾收集器。Serial、ParNew、Parallel GC、CMS 各自如何实现它们适合什么场景各有哪些坑第05篇将带你完整梳理传统垃圾收集器体系。系列导航上一篇【JVM深度解析】第03篇运行时数据区深度剖析下一篇【JVM深度解析】第05篇传统垃圾收集器总览系列目录JVM深度解析系列全集参考资料《深入理解Java虚拟机第3版》第3章 — 周志明著JVM Specification: Chapter 3 - Garbage CollectionGC Handbook权威 GC 理论参考Java Platform, Standard Edition HotSpot Virtual Machine GC Tuning GuideAleksey Shipilёv: Garbage Collection in JavaUnderstanding Java Garbage Collection