![[特殊字符] Java GC机制详解：G1、ZGC、Shenandoah全面解析与版本演进对比](images/news1.jpg)
本文核心价值✅ 全面解析G1、ZGC、Shenandoah三大GC回收器的底层原理与回收流程✅ 实战参数配置可直接用于项目调优✅ 核心对比表格一图看清三者差异✅ 澄清关键认知高版本JDK并未放弃G1而是优化选型逻辑 一、三大核心GC回收器详细解析G1、ZGC、Shenandoah是Java不同版本的核心GC回收器三者定位不同、设计理念各异分别适配不同的业务场景表格回收器诞生版本核心定位G1JDK7引入JDK8默认通用型兼顾吞吐量与延迟ZGCJDK11预览JDK17正式超低延迟TB级大内存ShenandoahJDK12预览JDK17正式低延迟与G1兼容性强 1.1 G1垃圾回收器Garbage-First—— 通用型兼顾吞吐量与延迟G1是Oracle官方推出的区域分代式垃圾回收器于JDK7中首次引入JDK8u20及以后版本成为默认GCJDK8早期版本默认Parallel GCJDK9-JDK20持续作为默认GC是Java历史上应用最广泛的通用型回收器核心定位是兼顾吞吐量与延迟适配绝大多数常规业务场景。 核心设计原理G1的核心设计理念是优先回收垃圾最多的区域Garbage-First采用区域分代模型无需手动分代调整自动管理年轻代与老年代支持大内存最大可支持数TB内存平衡吞吐量与延迟的同时避免CMS回收器的内存碎片问题。区域分代模型将JVM堆内存划分为多个大小相等的独立区域Region每个Region的大小可配置1MB~32MB默认根据堆内存自动计算区域类型分为三种表格区域类型存放对象回收算法回收频率Eden Region伊甸区新创建的对象复制算法⭐⭐⭐ 最高Survivor Region幸存区Minor GC后存活的对象复制算法⭐⭐⭐ 最高Old Region老年代存活时间较长的对象标记-整理⭐ 较低G1核心特点没有固定的年轻代和老年代边界通过动态调整各区域的数量实现年轻代与老年代的灵活管理兼顾吞吐量与延迟可通过参数控制最大GC停顿时间✅无内存碎片适合大内存场景。 垃圾回收流程核心三步G1的垃圾回收分为Minor GC年轻代回收、Mixed GC混合回收、Full GC全局回收三种其中Minor GC和Mixed GC是核心Full GC尽量避免会导致长停顿。 ① Minor GC年轻代回收—— ⚡ 停顿短毫秒级触发条件Eden Region满时触发回收过程采用复制算法将Eden Region和From Survivor Region中存活的对象复制到To Survivor Region若对象存活时间达到阈值默认15则晋升到Old Region回收完成后Eden和From Survivor清空To Survivor与From Survivor角色互换停顿特点只回收年轻代区域停顿时间较短毫秒级对主线程影响较小 ② Mixed GC混合回收—— ⚡ 可控停顿触发条件老年代区域占比达到阈值默认45%触发混合回收回收过程同时回收年轻代EdenSurvivor和部分老年代Region优先回收垃圾最多的Region即Garbage-First采用复制算法年轻代 标记-整理算法老年代停顿特点停顿时间比Minor GC长但比Full GC短可通过参数控制停顿时间上限如设置最大停顿时间为200ms ③ Full GC全局回收⚠️ 尽量避免触发条件Mixed GC无法回收足够内存、老年代满、元空间满等极端情况回收过程停止所有主线程STWStop The World对整个堆内存进行全面回收采用标记-整理算法停顿特点停顿时间极长秒级会严重影响系统可用性是G1的核心性能痛点⚠️关键提醒Full GC是G1最大的性能痛点调优的核心目标就是减少Full GC的发生频率 核心参数配置实战必配G1的默认参数基本适配常规场景针对高并发、大内存项目需手动调整参数优化性能核心参数如下bash# 1. 启用G1垃圾回收器JDK8u20及以后默认手动配置可兼容低版本 -XX:UseG1GC # 2. 设置堆内存大小建议设置为物理内存的1/2~2/3 -Xms4g -Xmx4g # 3. ⭐⭐⭐ 设置最大GC停顿时间核心参数根据业务延迟要求调整 -XX:MaxGCPauseMillis200 # 4. 设置年轻代占比默认0.4可根据业务调整范围0.1~0.9 -XX:G1NewSizePercent40 -XX:G1MaxNewSizePercent70 # 5. ⭐⭐ 设置老年代触发混合回收的阈值默认45%降低可减少Full GC -XX:InitiatingHeapOccupancyPercent40 # 6. 禁用ExplicitGC避免System.gc()触发Full GC -XX:DisableExplicitGC # 7. 设置Region大小默认自动计算手动设置需为2的幂1MB~32MB -XX:G1HeapRegionSize4m 1.2 ZGC垃圾回收器 —— 低延迟大内存首选 ZGC是Oracle研发的低延迟垃圾回收器首次在JDK11中以预览特性引入JDK17中正式稳定JDK21中进一步优化推出分代ZGCGenerational ZGC核心定位是超低延迟、支持超大内存解决G1在大内存场景下的长停顿问题适配延迟敏感型、大内存业务如金融交易、实时数据处理。 核心设计原理ZGC的核心设计目标是GC停顿时间控制在毫秒级以内通常10ms支持TB级堆内存其设计理念摒弃了G1的分代模型早期无分代JDK21引入分代采用基于Region的无分代或分代模型通过两大核心技术实现大部分GC操作与用户线程并发执行表格核心技术作用优势颜色指针通过给对象指针添加颜色标记记录对象的回收状态可达、不可达、正在迁移无需维护复杂的记忆集✅减少内存开销和GC耗时读屏障在读取对象指针时插入一段轻量代码实现并发迁移对象时的指针修正避免用户线程访问到无效对象✅无需冻结用户线程ZGC核心特点低延迟STW停顿10ms支持TB级堆内存 大部分GC操作与用户线程并发执行对业务影响极小 JDK21引入分代ZGC结合分代假设与ZGC的超低延迟✅进一步提升吞吐量年轻代采用复制算法老年代采用并发转移无内存碎片内存利用率高 垃圾回收流程核心四步几乎无长停顿ZGC的回收流程全程以并发为核心仅在2个阶段有极短的STW停顿微秒级或毫秒级其余阶段均与用户线程并发执行彻底解决G1的长停顿痛点。表格步骤阶段名称类型说明①初始标记STW标记与GC Roots直接关联的对象停顿时间极短微秒级与堆内存大小无关仅与GC Roots数量相关②并发标记并发遍历对象图标记出所有可达对象与用户线程并发执行耗时取决于堆中存活对象数量③并发预备重分配并发筛选出需要回收的Region垃圾占比高的Region准备进行对象迁移与用户线程并发执行④并发重分配与并发重映射并发将回收Region中的存活对象迁移到新的Region同时通过读屏障修正所有指向旧对象的指针✅全程与用户线程并发执行无STW停顿对比G1G1的回收阶段复制/整理需要STW而ZGC的整个回收过程几乎都是并发执行的这是ZGC实现超低延迟的根本原因。 核心参数配置实战必配ZGC仅支持JDK11及以上版本核心参数配置简洁重点关注堆内存、并发线程数等适配低延迟场景bash# 1. 启用ZGC垃圾回收器JDK11预览JDK17正式稳定 -XX:UseZGC # 2. 设置堆内存大小支持TB级根据业务需求调整 -Xms16g -Xmx16g # 3. 设置ZGC并发线程数默认是CPU核心数的1/8可根据CPU性能调整 -XX:ZGCThreads8 # 4. ⭐⭐⭐ 启用分代ZGCJDK21支持提升吞吐量 -XX:ZGenerational # 5. 设置ZGC内存释放延迟默认300秒可调整为立即释放 -XX:ZUncommitDelay0 1.3 Shenandoah垃圾回收器 —— 低延迟兼容多场景Shenandoah是由RedHat独立研发的低延迟垃圾回收器2014年RedHat将其贡献给OpenJDK首次在JDK12中以预览特性引入JDK17中正式稳定⚠️ Oracle JDK中未集成仅OpenJDK支持核心定位与ZGC一致——低延迟、支持大内存但设计细节与ZGC存在差异更注重兼容性和灵活性。 核心设计原理Shenandoah与G1有诸多相似之处二者都使用基于Region的堆内存布局且有着用于存放大对象的Humongous Region默认的回收策略也同样是优先处理回收价值最大的Region甚至在初始标记、并发标记等阶段的思路高度一致共享了一部分代码。但Shenandoah相比G1有三大核心改进实现了更低的延迟表格核心技术作用与G1的区别并发整理算法GC线程垃圾收集的过程中可以和用户线程并发执行G1的回收阶段可以多线程并行但无法与用户线程并发连接矩阵用二维表格记录跨Region的引用关系✅替代记忆集G1耗费大量内存和计算资源去维护记忆集Brooks指针通过转发指针记录对象的新地址确保用户线程能正确访问正在迁移的对象G1迁移对象时需要STW通俗理解连接矩阵连接矩阵可简单理解为一张二维表格若Region N有对象指向Region M就在表格的N行M列中打上标记回收时通过这张表格即可得知哪些Region之间存在跨代引用。 垃圾回收流程核心八步3次短STWShenandoah的回收流程分为8个阶段其中仅3个阶段有短暂的STW停顿其余阶段均与用户线程并发执行停顿时间极短且与堆内存大小无关仅与GC Roots数量相关。表格步骤阶段名称类型说明①初始标记STW与G1、ZGC一致标记与GC Roots直接关联的对象停顿时间极短②并发标记并发遍历对象图标记出全部可达的对象与用户线程并发执行时间长短取决于堆中存活对象的数量及对象图结构复杂度③最终标记STW处理剩余的SATB扫描统计出回收价值最高的Region构成回收集停顿时间短暂④并发清理并发清理整个区域内无存活对象的Immediate Garbage Region与用户线程并发执行⑤并发回收核心差异并发将回收集中的存活对象复制到其他未使用的Region通过Brooks指针解决并发迁移与访问的冲突与用户线程并发执行⑥初始引用更新STW建立线程集合点确保所有并发回收线程完成对象移动任务停顿时间极短⑦并发引用更新并发线性搜索内存中的引用类型将指向旧对象的引用修正为新地址与用户线程并发执行⑧最终引用更新STW修正GC Roots中的引用是Shenandoah的最后一次停顿停顿时间仅与GC Roots数量相关 核心参数配置实战必配Shenandoah仅支持JDK12及以上版本OpenJDK核心参数配置如下bash# 1. 启用Shenandoah垃圾回收器JDK12预览JDK17正式稳定仅OpenJDK支持 -XX:UseShenandoahGC # 2. 设置堆内存大小支持TB级根据业务需求调整 -Xms16g -Xmx16g # 3. 设置Shenandoah并发线程数默认CPU核心数的1/4可调整 -XX:ShenandoahGCThreads8 # 4. ⭐⭐ 设置Shenandoah回收模式默认iu并发回收可设为iu、satb等 -XX:ShenandoahGCHeuristicsiu # 5. 禁用Shenandoah分代默认禁用JDK17支持分代可启用 -XX:-ShenandoahGenerational 二、G1、ZGC、Shenandoah核心对比实战选型关键三者的核心差异集中在延迟、内存支持、并发能力、兼容性等方面以下从核心维度进行全面对比清晰区分各自的适用场景为项目选型提供依据表格对比维度 G1垃圾回收器 ZGC垃圾回收器 Shenandoah垃圾回收器核心定位通用型兼顾吞吐量与延迟低延迟超大内存支持低延迟兼容性强与G1兼容引入版本JDK7预览JDK8u20默认JDK11预览JDK17正式稳定JDK12预览JDK17正式稳定STW停顿时间毫秒级Minor GC~ 秒级Full GC大内存场景停顿明显毫秒级10ms几乎无长停顿与堆大小无关毫秒级10ms3次短STW与堆大小无关内存支持最大数TB理论实际常用16GB~64GB最大数TB✅支持TB级超大内存最大数TB✅支持TB级超大内存并发能力部分阶段并发如并发标记回收阶段并行无法与用户线程并发✅全程几乎并发仅2个短STW阶段并发能力最强✅全程几乎并发仅3个短STW阶段并发能力强核心技术区域分代模型、复制标记-整理算法 颜色指针、 读屏障、无分代JDK21分代 并发整理、 连接矩阵、 Brooks指针、无分代可选分代内存碎片✅ 无内存碎片标记-整理算法✅ 无内存碎片并发重分配✅ 无内存碎片并发整理兼容性✅✅✅所有JDK8版本支持生态最完善适配所有常规场景✅ JDK11支持Oracle JDK/OpenJDK均支持生态成熟⚠️JDK12支持仅OpenJDK支持Oracle JDK需额外集成调优复杂度 中等需调整停顿时间、Region大小等参数低参数简洁无需复杂调优 中等需调整并发线程数、回收模式等适用场景常规业务、单体/微服务、兼容性优先、无极致延迟要求低延迟业务、金融交易、实时数据、TB级大内存场景低延迟业务、OpenJDK环境、与G1兼容的迁移项目补充说明性能优先级低延迟场景下 ZGC ≈ Shenandoah G1吞吐量场景下 G1 ≈ ZGCJDK21分代 Shenandoah迁移成本从 G1迁移到 Shenandoah ✅成本最低二者设计相似迁移到 ZGC成本稍高需适配颜色指针、读屏障版本支持JDK8仅支持G1JDK11支持G1ZGC预览JDK17支持G1ZGC正式Shenandoah正式OpenJDK 三、关键澄清高版本JDK并未放弃G1而是优化选型逻辑很多开发者存在一个认知误区❌高版本JDKJDK17、JDK21放弃了G1转而使用ZGC/Shenandoah✅事实并非如此高版本JDK并未完全放弃G1而是调整了GC的默认选型逻辑——将G1作为通用兜底选项ZGC/Shenandoah作为低延迟、大内存场景的优先选项核心原因如下 3.1 高版本JDK对G1的态度保留持续优化从版本演进来看G1在高版本中始终被保留且持续优化JDK9-JDK20G1✅始终是默认GC回收器Oracle持续优化其STW停顿时间、混合回收效率解决G1的性能痛点JDK21默认GC调整为ZGC若硬件支持否则fallback到G1但G1仍被完整保留针对常规场景进行了进一步优化核心原因G1的通用性是ZGC/Shenandoah无法替代的其兼顾吞吐量与延迟的特性适配绝大多数不需要极致低延迟的常规业务且生态最完善、兼容性最强无需开发者进行复杂适配 3.2 高版本优先推荐ZGC/Shenandoah的核心原因并非放弃G1高版本JDK将ZGC/Shenandoah作为低延迟场景的优先选项核心是为了适配云计算、高并发、大内存的现代业务需求弥补G1的不足具体原因如下❶ G1的性能瓶颈无法彻底解决G1的混合回收、Full GC仍会产生长停顿秒级在TB级大内存、低延迟场景如金融交易、实时流处理中无法满足业务需求而ZGC/Shenandoah的STW停顿控制在10ms以内✅彻底解决长停顿痛点这是高版本优先推荐二者的核心原因❷ 现代业务对低延迟、大内存的需求提升随着云计算、微服务、实时数据处理的普及越来越多的业务如支付、直播、物联网对延迟敏感且需要TB级大内存支持如大数据平台ZGC/Shenandoah的设计理念完全适配这些场景而G1在这类场景下的性能表现不足❸ ZGC/Shenandoah的成熟度提升JDK17之后ZGC和Shenandoah已成为正式稳定特性生态逐渐完善兼容性不断提升能够满足企业级生产环境的需求而JDK21对ZGC的优化分代ZGC进一步弥补了其吞吐量不足的问题使其既能满足低延迟又能兼顾吞吐量竞争力大幅提升❹ 选型逻辑的优化高版本JDK的GC选型逻辑更贴合业务场景——常规业务无极致延迟要求仍可使用G1低延迟、大内存业务优先使用ZGC/Shenandoah而非一刀切放弃G1实现了✅通用场景兜底、特殊场景优化的平衡 3.3 高版本JDK中G1的定位仍有不可替代的价值即使ZGC/Shenandoah已成熟G1在高版本中仍有不可替代的价值主要适配以下场景表格场景为什么选G1常规业务场景无需极致低延迟追求吞吐量与延迟的平衡如传统单体应用、普通微服务兼容性优先场景项目依赖的框架、中间件对ZGC/Shenandoah适配不足✅G1的生态最完善适配所有Java框架低内存场景堆内存较小16GBZGC/Shenandoah的低延迟优势不明显✅G1的性能更优、资源消耗更低迁移过渡场景从JDK8升级到高版本的项目继续使用G1 ✅可降低迁移成本无需修改大量配置❓ 四、常见问题解答GC选型高频Q1JDK8中能否使用ZGC/Shenandoah❌不能。ZGC首次出现在JDK11预览Shenandoah首次出现在JDK12JDK8的GC体系中没有这两种回收器强行配置相关参数会报错JDK8仅支持G1、Parallel、Serial、CMS四种回收器。Q2JDK17/JDK21中G1、ZGC、Shenandoah该如何选型✅ 优先根据业务场景选型① 低延迟、大内存16GB、延迟敏感如金融、实时优先选 ZGCOracle JDK或 ShenandoahOpenJDK② 常规业务、兼容性优先、无极致延迟要求选 G1③ 低内存16GB、追求简单配置选 G1Q3高版本JDK放弃G1了吗为什么❌没有放弃。高版本JDK只是将ZGC/Shenandoah作为低延迟、大内存场景的优先选项G1仍被保留并持续优化核心原因是G1的通用性强、生态完善适配绝大多数常规业务而ZGC/Shenandoah主要解决G1在低延迟、大内存场景下的性能瓶颈✅二者互补而非替代。Q4ZGC和Shenandoah哪个更好二者定位一致各有优势表格对比项 ZGC ShenandoahJDK支持✅ Oracle JDK原生支持⚠️ 仅OpenJDK支持生态成熟度✅ ✅更成熟一般迁移成本稍高需适配颜色指针/读屏障✅ ✅最低与G1设计相似适合场景Oracle JDK环境、极致低延迟场景OpenJDK环境、从G1迁移的项目Q5G1的Full GC频繁该如何优化️优化步骤①优先调整InitiatingHeapOccupancyPercent参数降低老年代触发混合回收的阈值如 45% → 40%让Mixed GC提前触发减少老年代堆积②检查是否有大对象频繁创建、对象内存泄漏等问题③适当✅增大堆内存避免内存不足④若仍无法解决可考虑✅升级JDK版本使用ZGC/Shenandoah 五、总结表格GC回收器核心定位关键优势最佳场景G1通用兜底兼顾吞吐与延迟✅生态最完善常规业务、兼容性优先、低内存ZGC低延迟首选停顿 ✅10msOracle JDK支持金融交易、实时数据、TB级大内存Shenandoah低延迟兼容✅G1迁移成本最低OpenJDK环境、G1迁移项目关键认知高版本JDKJDK17、JDK21并未放弃G1而是优化了选型逻辑—— G1适配常规业务 ZGC/ Shenandoah适配低延迟、大内存业务不是替代而是互补。开发者在选型时无需盲目追新应结合JDK版本 × 业务延迟要求 × 堆内存大小 × 兼容性需求选择最适合的GC回收器。
[特殊字符] Java GC机制详解：G1、ZGC、Shenandoah全面解析与版本演进对比
本文核心价值✅ 全面解析G1、ZGC、Shenandoah三大GC回收器的底层原理与回收流程✅ 实战参数配置可直接用于项目调优✅ 核心对比表格一图看清三者差异✅ 澄清关键认知高版本JDK并未放弃G1而是优化选型逻辑 一、三大核心GC回收器详细解析G1、ZGC、Shenandoah是Java不同版本的核心GC回收器三者定位不同、设计理念各异分别适配不同的业务场景表格回收器诞生版本核心定位G1JDK7引入JDK8默认通用型兼顾吞吐量与延迟ZGCJDK11预览JDK17正式超低延迟TB级大内存ShenandoahJDK12预览JDK17正式低延迟与G1兼容性强 1.1 G1垃圾回收器Garbage-First—— 通用型兼顾吞吐量与延迟G1是Oracle官方推出的区域分代式垃圾回收器于JDK7中首次引入JDK8u20及以后版本成为默认GCJDK8早期版本默认Parallel GCJDK9-JDK20持续作为默认GC是Java历史上应用最广泛的通用型回收器核心定位是兼顾吞吐量与延迟适配绝大多数常规业务场景。 核心设计原理G1的核心设计理念是优先回收垃圾最多的区域Garbage-First采用区域分代模型无需手动分代调整自动管理年轻代与老年代支持大内存最大可支持数TB内存平衡吞吐量与延迟的同时避免CMS回收器的内存碎片问题。区域分代模型将JVM堆内存划分为多个大小相等的独立区域Region每个Region的大小可配置1MB~32MB默认根据堆内存自动计算区域类型分为三种表格区域类型存放对象回收算法回收频率Eden Region伊甸区新创建的对象复制算法⭐⭐⭐ 最高Survivor Region幸存区Minor GC后存活的对象复制算法⭐⭐⭐ 最高Old Region老年代存活时间较长的对象标记-整理⭐ 较低G1核心特点没有固定的年轻代和老年代边界通过动态调整各区域的数量实现年轻代与老年代的灵活管理兼顾吞吐量与延迟可通过参数控制最大GC停顿时间✅无内存碎片适合大内存场景。 垃圾回收流程核心三步G1的垃圾回收分为Minor GC年轻代回收、Mixed GC混合回收、Full GC全局回收三种其中Minor GC和Mixed GC是核心Full GC尽量避免会导致长停顿。 ① Minor GC年轻代回收—— ⚡ 停顿短毫秒级触发条件Eden Region满时触发回收过程采用复制算法将Eden Region和From Survivor Region中存活的对象复制到To Survivor Region若对象存活时间达到阈值默认15则晋升到Old Region回收完成后Eden和From Survivor清空To Survivor与From Survivor角色互换停顿特点只回收年轻代区域停顿时间较短毫秒级对主线程影响较小 ② Mixed GC混合回收—— ⚡ 可控停顿触发条件老年代区域占比达到阈值默认45%触发混合回收回收过程同时回收年轻代EdenSurvivor和部分老年代Region优先回收垃圾最多的Region即Garbage-First采用复制算法年轻代 标记-整理算法老年代停顿特点停顿时间比Minor GC长但比Full GC短可通过参数控制停顿时间上限如设置最大停顿时间为200ms ③ Full GC全局回收⚠️ 尽量避免触发条件Mixed GC无法回收足够内存、老年代满、元空间满等极端情况回收过程停止所有主线程STWStop The World对整个堆内存进行全面回收采用标记-整理算法停顿特点停顿时间极长秒级会严重影响系统可用性是G1的核心性能痛点⚠️关键提醒Full GC是G1最大的性能痛点调优的核心目标就是减少Full GC的发生频率 核心参数配置实战必配G1的默认参数基本适配常规场景针对高并发、大内存项目需手动调整参数优化性能核心参数如下bash# 1. 启用G1垃圾回收器JDK8u20及以后默认手动配置可兼容低版本 -XX:UseG1GC # 2. 设置堆内存大小建议设置为物理内存的1/2~2/3 -Xms4g -Xmx4g # 3. ⭐⭐⭐ 设置最大GC停顿时间核心参数根据业务延迟要求调整 -XX:MaxGCPauseMillis200 # 4. 设置年轻代占比默认0.4可根据业务调整范围0.1~0.9 -XX:G1NewSizePercent40 -XX:G1MaxNewSizePercent70 # 5. ⭐⭐ 设置老年代触发混合回收的阈值默认45%降低可减少Full GC -XX:InitiatingHeapOccupancyPercent40 # 6. 禁用ExplicitGC避免System.gc()触发Full GC -XX:DisableExplicitGC # 7. 设置Region大小默认自动计算手动设置需为2的幂1MB~32MB -XX:G1HeapRegionSize4m 1.2 ZGC垃圾回收器 —— 低延迟大内存首选 ZGC是Oracle研发的低延迟垃圾回收器首次在JDK11中以预览特性引入JDK17中正式稳定JDK21中进一步优化推出分代ZGCGenerational ZGC核心定位是超低延迟、支持超大内存解决G1在大内存场景下的长停顿问题适配延迟敏感型、大内存业务如金融交易、实时数据处理。 核心设计原理ZGC的核心设计目标是GC停顿时间控制在毫秒级以内通常10ms支持TB级堆内存其设计理念摒弃了G1的分代模型早期无分代JDK21引入分代采用基于Region的无分代或分代模型通过两大核心技术实现大部分GC操作与用户线程并发执行表格核心技术作用优势颜色指针通过给对象指针添加颜色标记记录对象的回收状态可达、不可达、正在迁移无需维护复杂的记忆集✅减少内存开销和GC耗时读屏障在读取对象指针时插入一段轻量代码实现并发迁移对象时的指针修正避免用户线程访问到无效对象✅无需冻结用户线程ZGC核心特点低延迟STW停顿10ms支持TB级堆内存 大部分GC操作与用户线程并发执行对业务影响极小 JDK21引入分代ZGC结合分代假设与ZGC的超低延迟✅进一步提升吞吐量年轻代采用复制算法老年代采用并发转移无内存碎片内存利用率高 垃圾回收流程核心四步几乎无长停顿ZGC的回收流程全程以并发为核心仅在2个阶段有极短的STW停顿微秒级或毫秒级其余阶段均与用户线程并发执行彻底解决G1的长停顿痛点。表格步骤阶段名称类型说明①初始标记STW标记与GC Roots直接关联的对象停顿时间极短微秒级与堆内存大小无关仅与GC Roots数量相关②并发标记并发遍历对象图标记出所有可达对象与用户线程并发执行耗时取决于堆中存活对象数量③并发预备重分配并发筛选出需要回收的Region垃圾占比高的Region准备进行对象迁移与用户线程并发执行④并发重分配与并发重映射并发将回收Region中的存活对象迁移到新的Region同时通过读屏障修正所有指向旧对象的指针✅全程与用户线程并发执行无STW停顿对比G1G1的回收阶段复制/整理需要STW而ZGC的整个回收过程几乎都是并发执行的这是ZGC实现超低延迟的根本原因。 核心参数配置实战必配ZGC仅支持JDK11及以上版本核心参数配置简洁重点关注堆内存、并发线程数等适配低延迟场景bash# 1. 启用ZGC垃圾回收器JDK11预览JDK17正式稳定 -XX:UseZGC # 2. 设置堆内存大小支持TB级根据业务需求调整 -Xms16g -Xmx16g # 3. 设置ZGC并发线程数默认是CPU核心数的1/8可根据CPU性能调整 -XX:ZGCThreads8 # 4. ⭐⭐⭐ 启用分代ZGCJDK21支持提升吞吐量 -XX:ZGenerational # 5. 设置ZGC内存释放延迟默认300秒可调整为立即释放 -XX:ZUncommitDelay0 1.3 Shenandoah垃圾回收器 —— 低延迟兼容多场景Shenandoah是由RedHat独立研发的低延迟垃圾回收器2014年RedHat将其贡献给OpenJDK首次在JDK12中以预览特性引入JDK17中正式稳定⚠️ Oracle JDK中未集成仅OpenJDK支持核心定位与ZGC一致——低延迟、支持大内存但设计细节与ZGC存在差异更注重兼容性和灵活性。 核心设计原理Shenandoah与G1有诸多相似之处二者都使用基于Region的堆内存布局且有着用于存放大对象的Humongous Region默认的回收策略也同样是优先处理回收价值最大的Region甚至在初始标记、并发标记等阶段的思路高度一致共享了一部分代码。但Shenandoah相比G1有三大核心改进实现了更低的延迟表格核心技术作用与G1的区别并发整理算法GC线程垃圾收集的过程中可以和用户线程并发执行G1的回收阶段可以多线程并行但无法与用户线程并发连接矩阵用二维表格记录跨Region的引用关系✅替代记忆集G1耗费大量内存和计算资源去维护记忆集Brooks指针通过转发指针记录对象的新地址确保用户线程能正确访问正在迁移的对象G1迁移对象时需要STW通俗理解连接矩阵连接矩阵可简单理解为一张二维表格若Region N有对象指向Region M就在表格的N行M列中打上标记回收时通过这张表格即可得知哪些Region之间存在跨代引用。 垃圾回收流程核心八步3次短STWShenandoah的回收流程分为8个阶段其中仅3个阶段有短暂的STW停顿其余阶段均与用户线程并发执行停顿时间极短且与堆内存大小无关仅与GC Roots数量相关。表格步骤阶段名称类型说明①初始标记STW与G1、ZGC一致标记与GC Roots直接关联的对象停顿时间极短②并发标记并发遍历对象图标记出全部可达的对象与用户线程并发执行时间长短取决于堆中存活对象的数量及对象图结构复杂度③最终标记STW处理剩余的SATB扫描统计出回收价值最高的Region构成回收集停顿时间短暂④并发清理并发清理整个区域内无存活对象的Immediate Garbage Region与用户线程并发执行⑤并发回收核心差异并发将回收集中的存活对象复制到其他未使用的Region通过Brooks指针解决并发迁移与访问的冲突与用户线程并发执行⑥初始引用更新STW建立线程集合点确保所有并发回收线程完成对象移动任务停顿时间极短⑦并发引用更新并发线性搜索内存中的引用类型将指向旧对象的引用修正为新地址与用户线程并发执行⑧最终引用更新STW修正GC Roots中的引用是Shenandoah的最后一次停顿停顿时间仅与GC Roots数量相关 核心参数配置实战必配Shenandoah仅支持JDK12及以上版本OpenJDK核心参数配置如下bash# 1. 启用Shenandoah垃圾回收器JDK12预览JDK17正式稳定仅OpenJDK支持 -XX:UseShenandoahGC # 2. 设置堆内存大小支持TB级根据业务需求调整 -Xms16g -Xmx16g # 3. 设置Shenandoah并发线程数默认CPU核心数的1/4可调整 -XX:ShenandoahGCThreads8 # 4. ⭐⭐ 设置Shenandoah回收模式默认iu并发回收可设为iu、satb等 -XX:ShenandoahGCHeuristicsiu # 5. 禁用Shenandoah分代默认禁用JDK17支持分代可启用 -XX:-ShenandoahGenerational 二、G1、ZGC、Shenandoah核心对比实战选型关键三者的核心差异集中在延迟、内存支持、并发能力、兼容性等方面以下从核心维度进行全面对比清晰区分各自的适用场景为项目选型提供依据表格对比维度 G1垃圾回收器 ZGC垃圾回收器 Shenandoah垃圾回收器核心定位通用型兼顾吞吐量与延迟低延迟超大内存支持低延迟兼容性强与G1兼容引入版本JDK7预览JDK8u20默认JDK11预览JDK17正式稳定JDK12预览JDK17正式稳定STW停顿时间毫秒级Minor GC~ 秒级Full GC大内存场景停顿明显毫秒级10ms几乎无长停顿与堆大小无关毫秒级10ms3次短STW与堆大小无关内存支持最大数TB理论实际常用16GB~64GB最大数TB✅支持TB级超大内存最大数TB✅支持TB级超大内存并发能力部分阶段并发如并发标记回收阶段并行无法与用户线程并发✅全程几乎并发仅2个短STW阶段并发能力最强✅全程几乎并发仅3个短STW阶段并发能力强核心技术区域分代模型、复制标记-整理算法 颜色指针、 读屏障、无分代JDK21分代 并发整理、 连接矩阵、 Brooks指针、无分代可选分代内存碎片✅ 无内存碎片标记-整理算法✅ 无内存碎片并发重分配✅ 无内存碎片并发整理兼容性✅✅✅所有JDK8版本支持生态最完善适配所有常规场景✅ JDK11支持Oracle JDK/OpenJDK均支持生态成熟⚠️JDK12支持仅OpenJDK支持Oracle JDK需额外集成调优复杂度 中等需调整停顿时间、Region大小等参数低参数简洁无需复杂调优 中等需调整并发线程数、回收模式等适用场景常规业务、单体/微服务、兼容性优先、无极致延迟要求低延迟业务、金融交易、实时数据、TB级大内存场景低延迟业务、OpenJDK环境、与G1兼容的迁移项目补充说明性能优先级低延迟场景下 ZGC ≈ Shenandoah G1吞吐量场景下 G1 ≈ ZGCJDK21分代 Shenandoah迁移成本从 G1迁移到 Shenandoah ✅成本最低二者设计相似迁移到 ZGC成本稍高需适配颜色指针、读屏障版本支持JDK8仅支持G1JDK11支持G1ZGC预览JDK17支持G1ZGC正式Shenandoah正式OpenJDK 三、关键澄清高版本JDK并未放弃G1而是优化选型逻辑很多开发者存在一个认知误区❌高版本JDKJDK17、JDK21放弃了G1转而使用ZGC/Shenandoah✅事实并非如此高版本JDK并未完全放弃G1而是调整了GC的默认选型逻辑——将G1作为通用兜底选项ZGC/Shenandoah作为低延迟、大内存场景的优先选项核心原因如下 3.1 高版本JDK对G1的态度保留持续优化从版本演进来看G1在高版本中始终被保留且持续优化JDK9-JDK20G1✅始终是默认GC回收器Oracle持续优化其STW停顿时间、混合回收效率解决G1的性能痛点JDK21默认GC调整为ZGC若硬件支持否则fallback到G1但G1仍被完整保留针对常规场景进行了进一步优化核心原因G1的通用性是ZGC/Shenandoah无法替代的其兼顾吞吐量与延迟的特性适配绝大多数不需要极致低延迟的常规业务且生态最完善、兼容性最强无需开发者进行复杂适配 3.2 高版本优先推荐ZGC/Shenandoah的核心原因并非放弃G1高版本JDK将ZGC/Shenandoah作为低延迟场景的优先选项核心是为了适配云计算、高并发、大内存的现代业务需求弥补G1的不足具体原因如下❶ G1的性能瓶颈无法彻底解决G1的混合回收、Full GC仍会产生长停顿秒级在TB级大内存、低延迟场景如金融交易、实时流处理中无法满足业务需求而ZGC/Shenandoah的STW停顿控制在10ms以内✅彻底解决长停顿痛点这是高版本优先推荐二者的核心原因❷ 现代业务对低延迟、大内存的需求提升随着云计算、微服务、实时数据处理的普及越来越多的业务如支付、直播、物联网对延迟敏感且需要TB级大内存支持如大数据平台ZGC/Shenandoah的设计理念完全适配这些场景而G1在这类场景下的性能表现不足❸ ZGC/Shenandoah的成熟度提升JDK17之后ZGC和Shenandoah已成为正式稳定特性生态逐渐完善兼容性不断提升能够满足企业级生产环境的需求而JDK21对ZGC的优化分代ZGC进一步弥补了其吞吐量不足的问题使其既能满足低延迟又能兼顾吞吐量竞争力大幅提升❹ 选型逻辑的优化高版本JDK的GC选型逻辑更贴合业务场景——常规业务无极致延迟要求仍可使用G1低延迟、大内存业务优先使用ZGC/Shenandoah而非一刀切放弃G1实现了✅通用场景兜底、特殊场景优化的平衡 3.3 高版本JDK中G1的定位仍有不可替代的价值即使ZGC/Shenandoah已成熟G1在高版本中仍有不可替代的价值主要适配以下场景表格场景为什么选G1常规业务场景无需极致低延迟追求吞吐量与延迟的平衡如传统单体应用、普通微服务兼容性优先场景项目依赖的框架、中间件对ZGC/Shenandoah适配不足✅G1的生态最完善适配所有Java框架低内存场景堆内存较小16GBZGC/Shenandoah的低延迟优势不明显✅G1的性能更优、资源消耗更低迁移过渡场景从JDK8升级到高版本的项目继续使用G1 ✅可降低迁移成本无需修改大量配置❓ 四、常见问题解答GC选型高频Q1JDK8中能否使用ZGC/Shenandoah❌不能。ZGC首次出现在JDK11预览Shenandoah首次出现在JDK12JDK8的GC体系中没有这两种回收器强行配置相关参数会报错JDK8仅支持G1、Parallel、Serial、CMS四种回收器。Q2JDK17/JDK21中G1、ZGC、Shenandoah该如何选型✅ 优先根据业务场景选型① 低延迟、大内存16GB、延迟敏感如金融、实时优先选 ZGCOracle JDK或 ShenandoahOpenJDK② 常规业务、兼容性优先、无极致延迟要求选 G1③ 低内存16GB、追求简单配置选 G1Q3高版本JDK放弃G1了吗为什么❌没有放弃。高版本JDK只是将ZGC/Shenandoah作为低延迟、大内存场景的优先选项G1仍被保留并持续优化核心原因是G1的通用性强、生态完善适配绝大多数常规业务而ZGC/Shenandoah主要解决G1在低延迟、大内存场景下的性能瓶颈✅二者互补而非替代。Q4ZGC和Shenandoah哪个更好二者定位一致各有优势表格对比项 ZGC ShenandoahJDK支持✅ Oracle JDK原生支持⚠️ 仅OpenJDK支持生态成熟度✅ ✅更成熟一般迁移成本稍高需适配颜色指针/读屏障✅ ✅最低与G1设计相似适合场景Oracle JDK环境、极致低延迟场景OpenJDK环境、从G1迁移的项目Q5G1的Full GC频繁该如何优化️优化步骤①优先调整InitiatingHeapOccupancyPercent参数降低老年代触发混合回收的阈值如 45% → 40%让Mixed GC提前触发减少老年代堆积②检查是否有大对象频繁创建、对象内存泄漏等问题③适当✅增大堆内存避免内存不足④若仍无法解决可考虑✅升级JDK版本使用ZGC/Shenandoah 五、总结表格GC回收器核心定位关键优势最佳场景G1通用兜底兼顾吞吐与延迟✅生态最完善常规业务、兼容性优先、低内存ZGC低延迟首选停顿 ✅10msOracle JDK支持金融交易、实时数据、TB级大内存Shenandoah低延迟兼容✅G1迁移成本最低OpenJDK环境、G1迁移项目关键认知高版本JDKJDK17、JDK21并未放弃G1而是优化了选型逻辑—— G1适配常规业务 ZGC/ Shenandoah适配低延迟、大内存业务不是替代而是互补。开发者在选型时无需盲目追新应结合JDK版本 × 业务延迟要求 × 堆内存大小 × 兼容性需求选择最适合的GC回收器。
