核心内容摘要
LLSAPP解锁数字生活新次元，智慧赋能无限可能
根基可达性分析的具体原理机制GC的核心前提是“精准识别垃圾”——判断哪些对象已不再被使用。
早期“引用计数法”因循环引用缺陷被淘汰HotSpot虚拟机采用的可达性分析算法是当前最成熟、通用的垃圾判定方案。
核心思想以“GC Roots”为起点构建对象引用关系图遍历所有可达对象并标记为“存活”未被标记的对象则判定为垃圾等待回收。
类比来看GC Roots如同“树根”可达对象是延伸的“树枝”垃圾便是脱离主干的“枯叶”。
GC Roots的具体分类面试高频并非所有对象都能作为GC Roots仅“绝对不会被回收”的核心引用可担当具体分为4类虚拟机栈引用对象栈帧中局部变量表、操作数栈引用的对象如方法内定义的局部变量方法区静态属性引用对象类的static变量引用的对象例private static User user new User()方法区常量引用对象字符串常量池、Class常量引用的对象本地方法栈引用对象Native方法如JNI调用引用的对象。
具体实现、核心组件与回收器差异可达性分析的高效执行依赖HotSpot底层机制支撑不同回收器为适配性能目标在实现细节、组件选型上差异显著。
以下从核心流程、关键组件、回收器差异三方面拆解兼顾原理与实战。
1可达性分析的核心实现流程完整流程分为“根枚举-对象图遍历-并发修正”三步每一步均经针对性优化平衡准确性与执行效率根枚举基于OopMap的快速定位根枚举的核心是高效找到所有GC RootsHotSpot通过OopMap普通对象指针映射表规避全栈遍历的低效问题。
在方法JIT编译、类加载阶段虚拟机自动记录栈帧中引用类型数据的内存偏移量并生成OopMap。
初始标记阶段STW无需遍历整个虚拟机栈/本地方法栈仅扫描OopMap记录位置即可快速定位根引用对象此阶段耗时可压缩至毫秒级。
同时方法区的静态属性、常量引用通过遍历元数据Class对象静态变量表、常量池补充结合OopMap完成全量GC Roots枚举。
对象图遍历分层优化减少扫描范围从根引用出发通过对象头引用指针递归遍历可达对象标记对象头Mark Word中的“存活标记位”。
为避免全堆扫描分代场景用卡表处理跨代引用分区场景用记忆集处理跨Region引用仅针对性扫描关联区域大幅降低遍历开销。
并发修正解决并发标记漏标问题现代回收器G1/ZGC为减少STW时间采用并发标记需通过特殊机制修正应用线程修改引用导致的漏标不同回收器的解决方案差异明显下文将结合回收器特性详细说明。
2卡表Card Table的具体实现卡表是分代回收场景中处理“老年代→年轻代”跨代引用的核心组件本质是“空间换时间”避免跨代遍历全堆其底层细节直接影响回收效率核心结构卡表是一块连续内存区域按512字节粒度将老年代划分为若干“卡页”每个卡页对应卡表中1字节标记位。
标记位分“干净”无跨代引用和“肮脏”存在老年代→年轻代引用两种状态通过位运算实现快速更新与读取。
标记触发机制当老年代对象引用年轻代对象时虚拟机通过**写屏障Write Barrier**自动标记对应卡页为“肮脏”。
写屏障是插入在对象引用赋值操作后的轻量代码无需开发者干预仅增加微小开销即可精准追踪跨代引用变更。
扫描与清理逻辑年轻代GC时无需遍历整个老年代仅扫描卡表中“肮脏”卡页逐个检查页内老年代对象是否引用年轻代存活对象验证后将卡页标记回“干净”显著减少扫描范围。
3不同回收器的实现差异对比各回收器因性能目标吞吐量/低延迟、内存管理模式分代/分区不同在可达性分析实现、跨引用处理组件上差异显著直接决定其适用场景回收器类型可达性分析核心实现跨引用处理组件并发漏标解决方案Serial GC串行单线程执行OopMap根枚举全堆遍历全程STW无并发阶段卡表分代场景逻辑简单适配年轻代标记-复制无并发阶段无需漏标修正Parallel GC并行吞吐量优先多线程并行根枚举遍历STW时间短于Serial依赖OopMap优化卡表分代场景多线程并行扫描肮脏卡页提效无并发阶段无需漏标修正CMS GC并发低延迟初始/重新标记STWOopMap 并发标记减少STW占比卡表分代场景写屏障标记肮脏页重新标记阶段扫描增量标记重新标记修正并发漏标对象G1 GC分区均衡型初始/最终标记STWOopMap 并发标记按Region分区遍历Remembered Set记忆集 卡表每Region维护跨Region引用SATB快照原子化记录并发引用变更最终标记批量修正ZGC超低延迟大内存初始/最终标记STW颜色指针 全阶段并发遍历无全堆扫描无卡表/记忆集依赖颜色指针读屏障追踪跨Region引用读屏障拦截引用访问自动标记漏标对象无需快照补充Shenandoah GC与ZGC目标一致超低延迟但用软件层面转发指针替代颜色指针跨引用处理依赖连接矩阵无需硬件支持兼容性更强小堆
GB场景性能更优。
核心三大基础垃圾回收算法所有回收器的底层均基于以下三种算法或其组合优化算法的取舍直接决定回收器的性能特性也是适配不同场景的核心依据。
标记-清除算法Mark-Sweep最基础的GC算法分为“标记”与“清除”两个核心阶段标记通过可达性分析标记所有存活对象清除遍历内存区域释放未标记的垃圾对象将空闲内存加入链表管理。
优缺点实现简单、内存利用率高但会产生大量内存碎片可能导致大对象无法分配且清除阶段需遍历全堆效率随堆大小增长而下降稳定性差。
适用场景早期Serial GC老年代、CMS老年代核心算法。
标记-复制算法Mark-Copy为解决内存碎片问题设计核心思路是“空间换时间”适配对象存活率低的场景分区将内存划分为两个或多个等大区域仅使用其中一个From区标记复制通过可达性分析标记存活对象按顺序复制到空闲区域To区天然避免碎片切换互换From区与To区角色清空原From区供下次分配使用。
优缺点无内存碎片、回收效率高但内存利用率低需预留空闲区当对象存活率高时复制开销会显著增加。
适用场景年轻代对象朝生夕死存活率低如Serial、Parallel、ParNew等回收器的年轻代。
标记-整理算法Mark-Compact兼顾内存连续性与利用率是标记-清除算法的优化版适配对象存活率高的场景标记通过可达性分析标记所有存活对象与前两种算法一致整理将所有存活对象向内存一端移动集中形成连续空闲空间清除释放存活对象末尾的空闲内存统一管理供后续分配。
优缺点无内存碎片、内存利用率高但对象移动需更新引用指针带来额外开销执行效率略低于标记-复制。
适用场景老年代对象存活率高如Serial Old、Parallel Old回收器。
实战全类型JVM垃圾回收器解析JVM垃圾回收器可分为“经典分代回收器”基于分代假说与“新一代回收器”面向低延迟、大内存不同回收器的算法选型、执行流程适配不同场景需结合业务需求选择。
一经典分代回收器JDK 8及之前主流基于“分代假说”对象朝生夕死、存活越久越难回收将堆分为年轻代EdenSurvivor与老年代针对性采用算法平衡回收效率与内存利用率。
Serial GC串行回收器核心特性单线程执行回收全程STW实现最简单无线程交互开销适合资源受限场景。
算法选型年轻代标记-复制算法Eden:Survivor8:1仅用10%内存作为空闲区提升利用率老年代标记-整理算法。
执行过程年轻代回收Eden区满时触发复制存活对象到Survivor区并将对象年龄1年龄达标默认15则晋升老年代最终清空Eden与原Survivor区老年代回收老年代空间不足时触发标记存活对象并整理至内存一端释放空闲空间供后续分配。
适用场景单核CPU、客户端应用、小型服务对停顿不敏感JDK
3前为默认回收器。
Parallel GC并行回收器吞吐量优先核心特性多线程并行回收目标是最大化吞吐量应用运行时间/总时间JDK 8默认回收器适配后台运算场景。
算法选型年轻代并行标记-复制多线程同时执行标记与复制加速回收老年代并行标记-整理多线程并行标记整理缩短STW时间。
执行过程与Serial GC核心流程一致仅将单线程操作改为多线程并行多核环境下STW时间显著缩短吞吐量大幅提升。
适用场景后台运算、科学计算、大数据处理对吞吐量要求高可容忍百毫秒级停顿。
ParNew GC并行年轻代回收器核心特性Serial GC的多线程版本仅负责年轻代回收需与CMS老年代回收器搭配使用是JDK
低延迟场景的过渡方案。
算法选型年轻代并行标记-复制与Parallel GC年轻代逻辑一致。
执行过程同Parallel GC年轻代回收仅作为CMS的“年轻代搭档”分担回收压力无独立老年代回收逻辑。
局限性JDK 9标记为废弃JDK 14正式移除被G1回收器全面替代。
CMS GC并发标记-清除回收器低延迟优先核心特性以最短停顿时间为目标老年代回收大部分工作与应用线程并发执行是JDK
低延迟场景的首选。
算法选型年轻代搭配ParNew采用并行标记-复制老年代并发标记-清除核心创新大幅减少STW时间。
执行过程老年代核心流程初始标记STW标记GC Roots直接关联对象耗时极短毫秒级并发标记GC线程与应用线程并行遍历对象图标记存活对象无STW重新标记STW修正并发标记期间因应用线程修改引用导致的漏标耗时短于初始标记并发清除GC线程与应用线程并行清除未标记垃圾对象无STW。
优缺点停顿时间短但会产生内存碎片、占用CPU资源并发阶段影响吞吐量无法处理浮动垃圾并发清除阶段产生的新垃圾需下次GC回收。
局限性JDK 9废弃JDK 14移除被G1/ZGC替代。
二新一代回收器JDK 9主流低延迟、大内存打破分代回收的严格边界采用Region分区管理堆内存兼顾吞吐量与低延迟支持TB级堆内存适配现代服务端场景。
G1 GCGarbage-First区域优先核心特性JDK 9默认回收器面向服务端应用通过“优先回收垃圾最多的Region”实现可控停顿时间平衡延迟与吞吐量。
核心设计将堆划分为多个大小相等的Region1MB~32MB自动计算每个Region可动态作为Eden、Survivor、Old区支持混合回收年轻代部分老年代。
算法选型整体标记-整理局部标记-复制Region间复制存活对象避免碎片。
执行过程混合回收核心流程初始标记STW依附于Young GC执行标记GC Roots直接关联对象同时通过卡表定位老年代对年轻代的引用并发标记遍历对象图标记存活对象通过写屏障维护Remembered Set记录跨Region引用最终标记STW处理SATB机制记录的漏标对象修正标记结果筛选回收部分STW统计各Region回收收益释放空间/耗时优先选择高收益Region复制存活对象到空闲Region并清空原Region混合回收分批次回收年轻代部分老年代Region通过-XX:MaxGCPauseMillis默认200ms控制停顿时间。
适用场景中型到大型堆内存4GB~64GB对停顿时间有要求的服务端应用如电商、金融核心服务。
ZGCZ Garbage Collector超低延迟核心特性Oracle推出的新一代回收器目标是将停顿时间控制在10ms以内支持TB级堆内存全阶段并发仅初始/最终标记短暂STW。
核心创新采用颜色指针硬件级支持和读屏障替代传统写屏障并发开销仅为写屏障的1/5大幅提升并发效率。
算法选型并发标记并发整理无碎片适配大内存场景。
执行过程初始标记STW
ms标记GC Roots直接引用对象标记为灰色并发标记GC线程与应用线程并行按颜色指针流转标记灰→黑白→灰读屏障自动标记被引用的白色对象避免漏标并发整理选择垃圾占比超25%的Region复制存活对象到新Region通过颜色指针重定向引用最终标记STW1ms确认引用变更重置颜色指针状态并发清理释放无存活对象的Region更新元数据供后续分配。
适用场景大内存16GB、超低延迟场景如实时数据处理、云原生服务、高频交易系统。
Shenandoah GC红帽版低延迟回收器核心特性与ZGC目标一致超低延迟但采用软件层面转发指针替代颜色指针无需硬件支持兼容性更强支持分代优化。
核心创新转发指针对象头存储新地址实现引用重定向、连接矩阵优化跨Region引用追踪降低遍历开销。
算法选型并发标记并发整理。
与ZGC差异弱化硬件依赖小堆
GB场景性能更优分代管理更完善适合混合工作负载既有短期对象也有长期对象。
四、
总结回收器选型与调优核心选择GC回收器的核心是“匹配业务场景”而非追求“最先进”不同回收器的适配场景与调优方向差异显著。
回收器核心优势适用场景Serial GC简单高效无线程交互开销单核CPU、客户端应用Parallel GC吞吐量优先多核加速明显后台运算、大数据处理G1 GC可控停顿性能均衡服务端通用场景4GB堆内存ZGC/Shenandoah超低延迟支持TB级大内存实时服务、云原生大内存场景调优核心建议优先使用默认回收器JDK 9用G1通过GC日志分析瓶颈避免盲目切换回收器低延迟场景优先选ZGC/Shenandoah吞吐量场景首选Parallel GC通用服务端场景用G1即可控制堆大小避免过大导致GC时间过长根据硬件配置调整Region大小、并发线程数等参数贴合实际运行负载。
GC的本质是“内存管理的权衡艺术”——没有完美的回收器只有最适合业务的选择。
掌握底层原理、各回收器执行逻辑及差异才能在性能问题出现时快速定位、精准调优从容应对面试与线上实战挑战。
在Java开发中“垃圾回收GC”是绕不开的核心话题——它既帮我们规避了手动管理内存的繁琐也可能因不合理的回收策略引发线上性能瓶颈。
不少开发者对GC的理解停留在“自动回收垃圾”但背后的可达性分析原理、不同回收器的执行逻辑的差异才是面试和调优的关键。
本文将从底层原理到实际实现层层拆解先讲透可达性分析的核心机制再逐一剖析各代回收器的执行过程与算法选型帮你建立完整的GC知识体系。
根基可达性分析的具体原理机制GC的核心前提是“识别垃圾”——即判断哪些对象不再被使用。
早期的“引用计数法”因循环引用问题被淘汰而HotSpot虚拟机采用的可达性分析算法是当前最成熟、最通用的垃圾判定方案。
核心思想以“GC Roots”为起点构建对象引用关系图遍历所有可达的对象并标记为“存活”未被标记的对象则判定为“垃圾”等待回收。
类比来说GC Roots相当于“树根”可达对象是“树枝”垃圾则是脱离树干的“枯叶”。
GC Roots的具体分类面试高频并非所有对象都能作为GC Roots必须是“绝对不会被回收”的核心引用具体包括4类虚拟机栈引用对象栈帧中的局部变量表、操作数栈引用的对象比如方法内定义的局部变量方法区静态属性引用对象类的static变量引用的对象如private static User user new User()方法区常量引用对象字符串常量池、Class常量引用的对象本地方法栈引用对象Native方法如JNI调用引用的对象。
具体实现、核心组件与回收器差异可达性分析的高效执行依赖HotSpot底层的核心机制支撑同时不同回收器为适配性能目标在实现细节、组件选型上存在显著差异。
以下从核心实现、卡表机制、回收器差异三方面展开拆解底层逻辑。
1可达性分析的核心实现流程完整的可达性分析分为“根枚举-对象图遍历-并发修正”三步每一步均有针对性优化平衡准确性与效率根枚举基于OopMap的快速定位根枚举的核心是快速找到所有GC RootsHotSpot通过OopMap普通对象指针映射表规避全栈遍历的低效问题。
在方法JIT编译、类加载阶段虚拟机自动记录栈帧中局部变量表、操作数栈里引用类型数据的内存偏移量生成OopMap。
初始标记阶段STW无需遍历整个虚拟机栈/本地方法栈仅扫描OopMap记录的位置即可快速定位根引用对应的对象此阶段耗时可压缩至毫秒级。
此外方法区的静态属性、常量引用通过遍历元数据Class对象的静态变量表、常量池补充结合OopMap完成全量GC Roots枚举。
对象图遍历分层优化减少扫描范围从根引用出发通过对象头中的引用指针递归遍历可达对象标记对象头Mark Word中的“存活标记位”。
为避免全堆扫描不同内存管理模式分代/分区采用不同优化分代场景用卡表处理跨代引用分区场景用记忆集处理跨Region引用仅针对性扫描关联区域而非全堆遍历。
并发修正解决并发标记漏标问题现代回收器G1/ZGC为减少STW采用并发标记模式需通过特殊机制修正应用线程修改引用导致的漏标问题不同回收器方案差异显著后文详述。
2卡表Card Table的具体实现卡表是分代回收场景中处理“老年代→年轻代”跨代引用的核心组件本质是通过空间换时间避免跨代遍历全堆其底层实现细节直接影响回收效率核心结构卡表是一块连续的内存区域按**512字节**粒度将老年代划分为若干“卡页”每个卡页对应卡表中的一个标记位通常1字节。
标记位状态分为“干净”无跨代引用和“肮脏”存在老年代→年轻代引用通过位运算快速更新和读取。
标记触发机制当老年代对象引用年轻代对象时虚拟机通过**写屏障Write Barrier**自动标记对应卡页为“肮脏”。
写屏障是插入在对象引用赋值操作后的一段轻量代码无需开发者干预仅增加微小开销即可精准追踪跨代引用变更。
扫描与清理逻辑年轻代GC时无需遍历整个老年代仅扫描卡表中标记为“肮脏”的卡页逐个检查卡页内的老年代对象是否引用年轻代存活对象验证后将卡页标记回“干净”大幅减少扫描范围。
3不同回收器的实现差异对比各回收器因性能目标吞吐量/低延迟、内存管理模式分代/分区不同在可达性分析实现、卡表/记忆集使用上差异明显直接决定其适用场景回收器类型可达性分析核心实现跨引用处理组件并发漏标解决方案Serial GC串行单线程执行OopMap根枚举全堆遍历全程STW无并发阶段卡表分代场景逻辑简单仅适配年轻代标记-复制无并发阶段无需漏标修正Parallel GC并行吞吐量优先多线程并行根枚举遍历STW时间短于Serial依赖OopMap优化卡表分代场景多线程并行扫描肮脏卡页提升效率无并发阶段无需漏标修正CMS GC并发低延迟初始/重新标记STWOopMap 并发标记减少STW占比卡表分代场景写屏障标记肮脏页重新标记阶段扫描增量标记重新标记修正并发标记漏标对象G1 GC分区均衡型初始/最终标记STWOopMap 并发标记按Region分区遍历Remembered Set记忆集 卡表每个Region维护跨Region引用SATB快照原子化记录并发引用变更最终标记阶段批量修正ZGC超低延迟大内存初始/最终标记STW颜色指针 全阶段并发遍历无全堆扫描无卡表/记忆集依赖颜色指针读屏障追踪跨Region引用读屏障拦截引用访问自动标记漏标对象无需快照补充说明Shenandoah GC与ZGC目标一致均为超低延迟但采用软件层面的转发指针替代颜色指针跨引用处理依赖连接矩阵优化跨Region引用无需硬件支持兼容性更强小堆内存场景性能更优。
可达性分析并非遍历全堆对象而是分阶段高效执行同时解决跨代引用、并发漏标等问题初始标记仅标记GC Roots直接关联的对象此阶段需STWStop-The-World暂停应用线程但耗时极短仅扫描根引用不遍历对象图并发遍历从初始标记的对象出发并发遍历整个对象引用图标记所有存活对象无需STWGC线程与应用线程并行执行问题解决跨代引用通过“卡表Card Table”记录老年代对年轻代的引用避免全堆扫描G
ParNew等回收器均采用此方案并发漏标因应用线程修改引用可能导致部分对象漏标G1用SATB快照原子化机制、ZGC用读屏障标记确保标记准确性。
核心三大基础垃圾回收算法所有回收器的底层都基于以下三种算法或其组合优化不同算法的取舍直接决定回收器的性能特性
标记-清除算法Mark-Sweep最基础的算法分为“标记”和“清除”两阶段标记通过可达性分析标记所有存活对象清除遍历内存区域释放未标记的垃圾对象将空闲内存加入链表。
优缺点实现简单、内存利用率高但会产生大量内存碎片导致大对象无法分配且清除阶段需遍历全堆效率不稳定。
适用场景早期Serial GC老年代、CMS老年代核心算法。
标记-复制算法Mark-Copy为解决内存碎片问题设计核心是“空间换时间”分区将内存划分为两个或多个区域仅使用其中一个From区标记复制标记存活对象将其按顺序复制到空闲区域To区避免碎片切换互换From区和To区角色清空原From区。
优缺点无内存碎片、回收效率高但内存利用率低需预留空闲区存活对象多时复制开销大。
适用场景年轻代对象存活率低如Serial、Parallel、ParNew等回收器的年轻代。
标记-整理算法Mark-Compact兼顾内存连续性和利用率是标记-清除的优化版标记同可达性分析标记存活对象整理将所有存活对象向内存一端移动集中形成连续空间清除释放存活对象末尾的所有内存。
优缺点无碎片、内存利用率高但对象移动需更新引用指针开销较大。
适用场景老年代对象存活率高如Serial Old、Parallel Old回收器。
实战全类型JVM垃圾回收器解析JVM垃圾回收器分为“经典分代回收器”基于分代假说和“新一代回收器”面向低延迟、大内存不同回收器的算法选型、执行流程差异显著需结合业务场景选择。
一经典分代回收器JDK 8及之前主流基于“分代假说”对象朝生夕死、存活越久越难回收将堆分为年轻代EdenSurvivor和老年代针对性采用算法。
Serial GC串行回收器核心特性单线程回收全程STW最简单的回收器无线程交互开销。
算法选型年轻代标记-复制算法Eden:Survivor8:1仅用10%内存作为空闲区提升利用率老年代标记-整理算法。
执行过程年轻代回收Eden区满触发复制存活对象到Survivor区年龄1年龄达标默认15则晋升老年代清空Eden和原Survivor区老年代回收老年代空间不足触发标记存活对象并整理到内存一端释放空闲空间。
适用场景单核CPU、客户端应用、小型服务对停顿不敏感JDK
3前默认。
Parallel GC并行回收器吞吐量优先核心特性多线程并行回收目标是最大化吞吐量应用运行时间/总时间JDK 8默认回收器。
算法选型年轻代并行标记-复制多线程同时复制加速回收老年代并行标记-整理多线程并行标记整理减少STW时间。
执行过程与Serial GC流程一致仅将单线程操作改为多线程并行STW时间显著缩短多核环境下。
适用场景后台运算、科学计算、大数据处理对吞吐量要求高可容忍百毫秒级停顿。
ParNew GC并行年轻代回收器核心特性Serial GC的多线程版本仅负责年轻代回收必须与CMS老年代回收器搭配使用。
算法选型年轻代并行标记-复制与Parallel GC年轻代逻辑一致。
执行过程同Parallel GC年轻代回收仅作为CMS的“年轻代搭档”分担回收压力。
局限性JDK 9标记为废弃JDK 14移除被G1回收器替代。
CMS GC并发标记-清除回收器低延迟优先核心特性以最短停顿时间为目标老年代回收大部分工作与应用线程并发执行是JDK
中低延迟场景的首选。
算法选型年轻代搭配ParNew并行标记-复制老年代并发标记-清除核心创新减少STW。
执行过程老年代核心流程初始标记STW标记GC Roots直接关联的对象耗时极短毫秒级并发标记GC线程与应用线程并行遍历对象图标记存活对象无STW重新标记STW修正并发标记期间因应用线程修改引用导致的漏标耗时短于初始标记并发清除GC线程与应用线程并行清除未标记垃圾对象无STW。
优缺点停顿时间短但会产生内存碎片、占用CPU资源并发阶段影响吞吐量无法处理浮动垃圾并发清除阶段产生的新垃圾需下次GC回收。
局限性JDK 9废弃JDK 14移除被G1/ZGC替代。
二新一代回收器JDK 9主流低延迟、大内存打破分代回收的严格边界采用Region分区管理兼顾吞吐量和低延迟支持TB级堆内存。
G1 GCGarbage-First区域优先核心特性JDK 9默认回收器面向服务端应用通过“优先回收垃圾最多的Region”实现可控停顿时间。
核心设计将堆划分为多个大小相等的Region1MB~32MB自动计算每个Region可动态作为Eden、Survivor、Old区支持混合回收年轻代部分老年代。
算法选型整体标记-整理局部标记-复制Region间复制存活对象避免碎片。
执行过程混合回收核心流程初始标记STW依附于Young GC标记GC Roots直接关联对象同时通过卡表定位老年代对年轻代的引用并发标记遍历对象图标记存活对象通过写屏障维护Remembered Set记录跨Region引用最终标记STW处理SATB机制记录的漏标对象修正标记结果筛选回收部分STW统计各Region回收收益释放空间/耗时优先选择高收益Region复制存活对象到空闲Region清空原Region混合回收分批次回收年轻代部分老年代Region通过-XX:MaxGCPauseMillis默认200ms控制停顿时间。
适用场景中型到大型堆内存4GB~64GB对停顿时间有要求的服务端应用如电商、金融。
ZGCZ Garbage Collector超低延迟核心特性Oracle推出的新一代回收器目标是停顿时间控制在10ms以内支持TB级堆内存全阶段并发仅初始标记、最终标记短暂STW。
核心创新采用颜色指针硬件级支持和读屏障替代传统写屏障降低并发开销读屏障开销仅为写屏障的1/5。
算法选型并发标记并发整理无碎片。
执行过程初始标记STW
ms标记GC Roots直接引用对象标记为灰色并发标记GC线程与应用线程并行按颜色指针流转标记灰→黑白→灰读屏障自动标记被引用的白色对象并发整理选择垃圾占比超25%的Region复制存活对象到新Region通过颜色指针重定向引用最终标记STW1ms确认引用变更重置颜色指针并发清理释放无存活对象的Region更新元数据。
适用场景大内存16GB、超低延迟场景如实时数据处理、云原生服务。
Shenandoah GC红帽版低延迟回收器核心特性与ZGC目标一致但采用软件层面的转发指针无需硬件支持兼容性更强支持分代优化。
核心创新转发指针对象头存储新地址、连接矩阵优化跨Region引用。
算法选型并发标记并发整理。
与ZGC差异弱化硬件依赖小堆
GB性能更优分代管理更完善适合混合工作负载。
四、
总结回收器选型与调优核心选择GC回收器的核心是“匹配业务场景”而非追求“最先进”回收器核心优势适用场景Serial GC简单高效无线程开销单核、客户端应用Parallel GC吞吐量优先多核加速后台运算、大数据处理G1 GC可控停顿均衡性能服务端通用场景4GB堆ZGC/Shenandoah超低延迟大内存支持实时服务、云原生大内存场景调优核心建议优先用默认回收器JDK 9用G1通过GC日志分析瓶颈低延迟场景优先ZGC/Shenandoah吞吐量场景用Parallel GC控制堆大小避免过大导致GC时间长调整Region大小、并发线程数等参数匹配硬件。
GC的本质是“内存管理的权衡艺术”——没有完美的回收器只有最适合业务的选择。
掌握底层原理和各回收器的执行逻辑才能在性能问题出现时快速定位、精准调优。