第62篇垃圾回收器详解2026版系列导航《Java 100 天进阶之路》完整目录 |⬅️ 上一篇第61篇JVM内存区域 |➡️ 下一篇第63篇GC调优实战️ 本文阅读地图3 分钟速览第61篇搞定了JVM内存布局本篇深入垃圾回收器GC的核心世界。GC是JVM的“清道夫”选对回收器、调好参数是Java性能优化的核心技能模块核心问题一句话回答三大指标GC评判标准是什么吞吐量、延迟STW、内存占用——三者不可兼得六款回收器都有哪些GCSerial → Parallel → CMS → G1 → ZGC/Shenandoah四代演进默认GC各JDK版本默认是什么JDK 8 Parallel GCJDK 9 G1 GCG1为什么是主流大堆场景谁最稳G1是JDK 9默认GC兼顾吞吐与延迟6GB~64GB堆的黄金选择ZGC/Shenandoah极致低延迟用什么ZGC和Shenandoah亚毫秒级停顿JDK 21分代优化成熟CMS去哪了还在用CMS吗JDK 14已彻底移除存量JDK 8可迁移至G1面试最爱问高频考点有哪些见文末 小节一、核心知识点1. GC三大黄金指标所有垃圾回收器的设计都在三个指标间做权衡指标含义优先场景吞吐量Throughput业务执行时间 / (业务执行时间 GC总耗时)批处理、离线任务、后台计算延迟Latency / STWGC暂停业务线程的时间支付、网关、实时服务、Web应用内存占用FootprintGC占用的额外内存空间容器化环境、资源受限场景核心权衡三个指标无法同时做到极致——追求低延迟吞吐量会下降追求高吞吐停顿时间会变长。2. 四代GC演进脉络世代代表回收器诞生背景核心特点现状第一代串行SerialJDK 1.0Client模式默认单线程STW简单轻量仅小型应用第二代并行Parallel多核CPU普及追求吞吐量多线程STW吞吐优先JDK 8默认第三代并发CMS → G1低延迟需求CMS碎片问题并发回收G1分区化G1是JDK 9默认第四代低延迟ZGC / Shenandoah大堆100GB场景停顿过长亚毫秒级停顿并发全部操作JDK 21分代优化成熟3. 各JDK版本默认GC速查JDK版本默认GC说明JDK 8Parallel GCParallel Scavenge Parallel OldServer模式默认JDK 9 ~ 21G1 GCJDK 9起成为默认JDK 21可选ZGC分代ZGCJDK 21分代ZGC正式稳定超低延迟首选2026年现状G1仍是大多数项目的默认选择ZGC/Shenandoah在极致低延迟场景统治。二、通俗讲解1分钟开心学把GC想象成清理房间Serial GC你一个人打扫一整栋楼单线程干活时所有人都得停下等STW。适合小房子小堆。Parallel GC叫来一帮人一起打扫多线程干活时大家还是得停下但速度快多了。适合大厂房大堆、不赶时间对延迟不敏感。CMS GC请了保洁团队大部分时间边干活边打扫并发但打扫完地上会留灰内存碎片。偶尔保洁团队太忙还会撂挑子并发模式失败。G1 GC把整栋楼切成无数个小隔间Region每次只打扫垃圾最多的几个隔间Garbage-First。可以设定“每次最多打扫X分钟”停顿时间目标干不完下次再干。ZGC / Shenandoah保洁团队一边打扫一边让住户正常生活完全并发几乎感觉不到停顿亚毫秒级。适合摩天大楼超大堆、百GB级。一句话总结Serial是“一人包干”Parallel是“团队突击”CMS是“边干边扫”G1是“分区定点清除”ZGC/Shenandoah是“无感保洁”。三、各回收器深度解析3.1 Serial GC最基础的串行回收器核心特点单线程新生代用Serial复制算法老年代用Serial Old标记-整理算法STW回收时暂停所有用户线程适合场景Client模式、小型应用、堆内存100MB、单核CPU# 开启Serial GC-XX:UseSerialGC现状在2026年Serial GC基本只用于极简嵌入式环境或学习研究。3.2 Parallel GC吞吐量优先的并行回收器核心特点多线程并行新生代Parallel Scavenge复制算法老年代Parallel Old标记-整理算法吞吐量优先JDK 8默认GC目标是最大化应用程序运行时间占比STW仍会暂停所有用户线程但比Serial快# JDK 8默认也可显式开启-XX:UseParallelGC# 设置GC线程数默认等于CPU核数-XX:ParallelGCThreads8# 设置吞吐量目标默认99%-XX:GCTimeRatio99适用场景批处理、大数据计算、离线任务、对延迟不敏感的后台服务。3.3 CMS GC并发低延迟的先行者已淘汰核心特点并发标记-清除老年代回收大部分阶段与应用程序并发执行低停顿目标是缩短STW时间不压缩标记-清除算法产生内存碎片CMS的致命缺陷内存碎片长时间运行后碎片严重可能导致Full GCCPU敏感并发阶段占用CPU资源并发模式失败老年代空间不足时降级为Serial Old浮动垃圾并发清理时新产生的垃圾需下次处理# JDK 8中开启CMS已过时-XX:UseConcMarkSweepGC⚠️重要提醒CMS在JDK 9被标记为废弃JDK 14已彻底移除。JDK 8存量应用建议迁移至G1。3.4 G1 GCJDK 9默认的全能型回收器设计目标面向大堆内存6GB~64GB实现可预测的低停顿时间。核心机制机制说明Region分区将堆划分为多个大小相等的Region默认2048个每个Region可扮演Eden、Survivor、Old或Humongous角色Garbage-First策略优先回收垃圾最多的Region用最少时间释放最多空间停顿预测模型基于历史数据预测每次GC耗时确保不超过用户设定的停顿时间目标混合GC同时回收年轻代和部分老年代Region# 开启G1JDK 9默认-XX:UseG1GC# 设置最大停顿时间目标默认200ms-XX:MaxGCPauseMillis100# 设置Region大小2的幂1-32MB-XX:G1HeapRegionSize16m# 设置堆大小-Xmx16g适用场景绝大多数Web应用、微服务、电商中台JDK 9项目首选。四、实操代码案例 场景说明4.1 查看当前GC配置# 查看JVM默认GCjava-XX:PrintCommandLineFlags-version# 输出示例JDK 8-XX:UseParallelGC# 输出示例JDK 11-XX:UseG1GC# 查看正在运行的应用的GCjstat-gcpid1000# 输出各区域GC次数和耗时4.2 GC日志分析与参数配置# 生产级GC日志配置推荐-XX:PrintGCDetails-XX:PrintGCDateStamps-XX:PrintGCTimeStamps-Xloggc:/var/log/app-gc.log-XX:UseGCLogFileRotation-XX:NumberOfGCLogFiles10-XX:GCLogFileSize100MGC日志解读示例2026-07-22T10:00:01.1230800: 5.678: [GC pause (G1 Evacuation Pause) (young), 0.0152345 secs] [Eden: 512.0M(512.0M)-0.0B(512.0M) Survivors: 64.0M-64.0M Heap: 1.2G(4.0G)-700.0M(4.0G)]GC pauseSTW暂停0.0152345 secs暂停时间15msEden: 512M→0BEden区清空Heap: 1.2G→700M堆内存回收约500MB4.3 生产环境G1推荐配置模板# 通用G1配置4GB堆目标停顿100ms-Xms4g-Xmx4g-XX:UseG1GC-XX:MaxGCPauseMillis100-XX:G1HeapRegionSize8m-XX:PrintGCDetails-Xloggc:/var/log/gc.log-XX:HeapDumpOnOutOfMemoryError-XX:HeapDumpPath/var/log/heap.hprof4.4 GC调优决策树2026版应用是否需要 10ms 的 GC 停顿 ├─ 是 → 堆 16GB→ 是 → 考虑 ZGCJDK 21 分代 │ → 否 → 考虑 G1调低 MaxGCPauseMillis └─ 否 → 堆 4GB→ 是 → G1默认配置即可 → 否 → Parallel GC追求吞吐量五、避坑要点错误/误区后果正确做法盲目使用CMSJDK 9不支持JDK 14已移除迁移至G1无界设置-Xmx堆内存不足导致Full GC频繁根据业务负载合理设置G1堆太小4GBG1管理开销反而拖累性能小堆用Parallel GC忽略GC日志线上GC问题无法定位生产环境必开GC日志ZGC堆太小ZGC优势无法发挥ZGC推荐堆≥16GB六、面试高频考点Q1垃圾回收器有哪几种各版本JDK默认是什么六种主要回收器Serial、Parallel、CMS、G1、ZGC、Shenandoah。JDK 8默认Parallel GCJDK 9默认G1 GC。Q2G1为什么是JDK 9的默认GCG1通过Region化管理和优先级回收Garbage-First在大堆6GB~64GB场景下实现了延迟与吞吐量的有效折中。相比CMSG1能压缩内存避免碎片、提供可预测的停顿时间。Q3ZGC和G1的核心区别G1仍有STW停顿通常200msZGC将大部分GC操作并发化停顿时间1ms。ZGC采用着色指针读屏障实现并发转移。ZGC适合超大堆16GB~TB级和极致低延迟场景。Q4CMS为什么被淘汰内存碎片、并发模式失败、浮动垃圾三大缺陷。JDK 9废弃、JDK 14彻底移除。Q5ZGC的着色指针是什么ZGC利用64位指针的高几位存储对象元数据标记位无需在对象头中存储标记信息使标记和转移操作可完全并发进行。 面试官追问陷阱加分题追问1“G1的Region大小如何设置默认多少个” 默认最多2048个RegionRegion大小通过-XX:G1HeapRegionSize设置1~32MB。Region必须是2的幂堆≤64GB时G1表现最佳。追问2“ZGC在JDK 21有什么重要更新” JDK 21引入了分代ZGCGenerational ZGC进一步降低了CPU开销和内存占用。这是ZGC从实验性走向生产级的关键里程碑。七、练习题分析题某JDK 8应用使用CMS频繁出现Full GC导致服务超时。推荐什么优化方案为什么场景题一个金融交易系统堆内存32GB要求GC停顿10ms。推荐什么GC开启什么参数代码题配置生产环境G1 GC日志要求输出到/var/log/app-gc.log保留10个文件每个100MB。 你的学习进度当前第62篇 / 共108篇 ·进阶篇JVM调优与故障排查第61~70篇✅ 已完成基础篇44篇 第45~62篇 正在学第62篇⏳ 待学习第63~108篇 完整目录 学习指南 | 订阅本专栏不错过每一篇 下一篇文章预告下一篇《第63篇GC调优实战》内容简介GC日志分析实战、JVM参数调优、年轻代/老年代大小调整、G1/ZGC调参最佳实践、生产环境GC问题排查流程。JVM调优专题持续深入拿下GC调优实战《Java 100 天进阶之路 | 从入门到上岗就业》每天一篇建议收藏 关注一起100天拿offer 点击关注我更新后第一时间收到推送
第62篇垃圾回收器详解2026版系列导航《Java 100 天进阶之路》完整目录 |⬅️ 上一篇第61篇JVM内存区域 |➡️ 下一篇第63篇GC调优实战️ 本文阅读地图3 分钟速览第61篇搞定了JVM内存布局本篇深入垃圾回收器GC的核心世界。GC是JVM的“清道夫”选对回收器、调好参数是Java性能优化的核心技能模块核心问题一句话回答三大指标GC评判标准是什么吞吐量、延迟STW、内存占用——三者不可兼得六款回收器都有哪些GCSerial → Parallel → CMS → G1 → ZGC/Shenandoah四代演进默认GC各JDK版本默认是什么JDK 8 Parallel GCJDK 9 G1 GCG1为什么是主流大堆场景谁最稳G1是JDK 9默认GC兼顾吞吐与延迟6GB~64GB堆的黄金选择ZGC/Shenandoah极致低延迟用什么ZGC和Shenandoah亚毫秒级停顿JDK 21分代优化成熟CMS去哪了还在用CMS吗JDK 14已彻底移除存量JDK 8可迁移至G1面试最爱问高频考点有哪些见文末 小节一、核心知识点1. GC三大黄金指标所有垃圾回收器的设计都在三个指标间做权衡指标含义优先场景吞吐量Throughput业务执行时间 / (业务执行时间 GC总耗时)批处理、离线任务、后台计算延迟Latency / STWGC暂停业务线程的时间支付、网关、实时服务、Web应用内存占用FootprintGC占用的额外内存空间容器化环境、资源受限场景核心权衡三个指标无法同时做到极致——追求低延迟吞吐量会下降追求高吞吐停顿时间会变长。2. 四代GC演进脉络世代代表回收器诞生背景核心特点现状第一代串行SerialJDK 1.0Client模式默认单线程STW简单轻量仅小型应用第二代并行Parallel多核CPU普及追求吞吐量多线程STW吞吐优先JDK 8默认第三代并发CMS → G1低延迟需求CMS碎片问题并发回收G1分区化G1是JDK 9默认第四代低延迟ZGC / Shenandoah大堆100GB场景停顿过长亚毫秒级停顿并发全部操作JDK 21分代优化成熟3. 各JDK版本默认GC速查JDK版本默认GC说明JDK 8Parallel GCParallel Scavenge Parallel OldServer模式默认JDK 9 ~ 21G1 GCJDK 9起成为默认JDK 21可选ZGC分代ZGCJDK 21分代ZGC正式稳定超低延迟首选2026年现状G1仍是大多数项目的默认选择ZGC/Shenandoah在极致低延迟场景统治。二、通俗讲解1分钟开心学把GC想象成清理房间Serial GC你一个人打扫一整栋楼单线程干活时所有人都得停下等STW。适合小房子小堆。Parallel GC叫来一帮人一起打扫多线程干活时大家还是得停下但速度快多了。适合大厂房大堆、不赶时间对延迟不敏感。CMS GC请了保洁团队大部分时间边干活边打扫并发但打扫完地上会留灰内存碎片。偶尔保洁团队太忙还会撂挑子并发模式失败。G1 GC把整栋楼切成无数个小隔间Region每次只打扫垃圾最多的几个隔间Garbage-First。可以设定“每次最多打扫X分钟”停顿时间目标干不完下次再干。ZGC / Shenandoah保洁团队一边打扫一边让住户正常生活完全并发几乎感觉不到停顿亚毫秒级。适合摩天大楼超大堆、百GB级。一句话总结Serial是“一人包干”Parallel是“团队突击”CMS是“边干边扫”G1是“分区定点清除”ZGC/Shenandoah是“无感保洁”。三、各回收器深度解析3.1 Serial GC最基础的串行回收器核心特点单线程新生代用Serial复制算法老年代用Serial Old标记-整理算法STW回收时暂停所有用户线程适合场景Client模式、小型应用、堆内存100MB、单核CPU# 开启Serial GC-XX:UseSerialGC现状在2026年Serial GC基本只用于极简嵌入式环境或学习研究。3.2 Parallel GC吞吐量优先的并行回收器核心特点多线程并行新生代Parallel Scavenge复制算法老年代Parallel Old标记-整理算法吞吐量优先JDK 8默认GC目标是最大化应用程序运行时间占比STW仍会暂停所有用户线程但比Serial快# JDK 8默认也可显式开启-XX:UseParallelGC# 设置GC线程数默认等于CPU核数-XX:ParallelGCThreads8# 设置吞吐量目标默认99%-XX:GCTimeRatio99适用场景批处理、大数据计算、离线任务、对延迟不敏感的后台服务。3.3 CMS GC并发低延迟的先行者已淘汰核心特点并发标记-清除老年代回收大部分阶段与应用程序并发执行低停顿目标是缩短STW时间不压缩标记-清除算法产生内存碎片CMS的致命缺陷内存碎片长时间运行后碎片严重可能导致Full GCCPU敏感并发阶段占用CPU资源并发模式失败老年代空间不足时降级为Serial Old浮动垃圾并发清理时新产生的垃圾需下次处理# JDK 8中开启CMS已过时-XX:UseConcMarkSweepGC⚠️重要提醒CMS在JDK 9被标记为废弃JDK 14已彻底移除。JDK 8存量应用建议迁移至G1。3.4 G1 GCJDK 9默认的全能型回收器设计目标面向大堆内存6GB~64GB实现可预测的低停顿时间。核心机制机制说明Region分区将堆划分为多个大小相等的Region默认2048个每个Region可扮演Eden、Survivor、Old或Humongous角色Garbage-First策略优先回收垃圾最多的Region用最少时间释放最多空间停顿预测模型基于历史数据预测每次GC耗时确保不超过用户设定的停顿时间目标混合GC同时回收年轻代和部分老年代Region# 开启G1JDK 9默认-XX:UseG1GC# 设置最大停顿时间目标默认200ms-XX:MaxGCPauseMillis100# 设置Region大小2的幂1-32MB-XX:G1HeapRegionSize16m# 设置堆大小-Xmx16g适用场景绝大多数Web应用、微服务、电商中台JDK 9项目首选。四、实操代码案例 场景说明4.1 查看当前GC配置# 查看JVM默认GCjava-XX:PrintCommandLineFlags-version# 输出示例JDK 8-XX:UseParallelGC# 输出示例JDK 11-XX:UseG1GC# 查看正在运行的应用的GCjstat-gcpid1000# 输出各区域GC次数和耗时4.2 GC日志分析与参数配置# 生产级GC日志配置推荐-XX:PrintGCDetails-XX:PrintGCDateStamps-XX:PrintGCTimeStamps-Xloggc:/var/log/app-gc.log-XX:UseGCLogFileRotation-XX:NumberOfGCLogFiles10-XX:GCLogFileSize100MGC日志解读示例2026-07-22T10:00:01.1230800: 5.678: [GC pause (G1 Evacuation Pause) (young), 0.0152345 secs] [Eden: 512.0M(512.0M)-0.0B(512.0M) Survivors: 64.0M-64.0M Heap: 1.2G(4.0G)-700.0M(4.0G)]GC pauseSTW暂停0.0152345 secs暂停时间15msEden: 512M→0BEden区清空Heap: 1.2G→700M堆内存回收约500MB4.3 生产环境G1推荐配置模板# 通用G1配置4GB堆目标停顿100ms-Xms4g-Xmx4g-XX:UseG1GC-XX:MaxGCPauseMillis100-XX:G1HeapRegionSize8m-XX:PrintGCDetails-Xloggc:/var/log/gc.log-XX:HeapDumpOnOutOfMemoryError-XX:HeapDumpPath/var/log/heap.hprof4.4 GC调优决策树2026版应用是否需要 10ms 的 GC 停顿 ├─ 是 → 堆 16GB→ 是 → 考虑 ZGCJDK 21 分代 │ → 否 → 考虑 G1调低 MaxGCPauseMillis └─ 否 → 堆 4GB→ 是 → G1默认配置即可 → 否 → Parallel GC追求吞吐量五、避坑要点错误/误区后果正确做法盲目使用CMSJDK 9不支持JDK 14已移除迁移至G1无界设置-Xmx堆内存不足导致Full GC频繁根据业务负载合理设置G1堆太小4GBG1管理开销反而拖累性能小堆用Parallel GC忽略GC日志线上GC问题无法定位生产环境必开GC日志ZGC堆太小ZGC优势无法发挥ZGC推荐堆≥16GB六、面试高频考点Q1垃圾回收器有哪几种各版本JDK默认是什么六种主要回收器Serial、Parallel、CMS、G1、ZGC、Shenandoah。JDK 8默认Parallel GCJDK 9默认G1 GC。Q2G1为什么是JDK 9的默认GCG1通过Region化管理和优先级回收Garbage-First在大堆6GB~64GB场景下实现了延迟与吞吐量的有效折中。相比CMSG1能压缩内存避免碎片、提供可预测的停顿时间。Q3ZGC和G1的核心区别G1仍有STW停顿通常200msZGC将大部分GC操作并发化停顿时间1ms。ZGC采用着色指针读屏障实现并发转移。ZGC适合超大堆16GB~TB级和极致低延迟场景。Q4CMS为什么被淘汰内存碎片、并发模式失败、浮动垃圾三大缺陷。JDK 9废弃、JDK 14彻底移除。Q5ZGC的着色指针是什么ZGC利用64位指针的高几位存储对象元数据标记位无需在对象头中存储标记信息使标记和转移操作可完全并发进行。 面试官追问陷阱加分题追问1“G1的Region大小如何设置默认多少个” 默认最多2048个RegionRegion大小通过-XX:G1HeapRegionSize设置1~32MB。Region必须是2的幂堆≤64GB时G1表现最佳。追问2“ZGC在JDK 21有什么重要更新” JDK 21引入了分代ZGCGenerational ZGC进一步降低了CPU开销和内存占用。这是ZGC从实验性走向生产级的关键里程碑。七、练习题分析题某JDK 8应用使用CMS频繁出现Full GC导致服务超时。推荐什么优化方案为什么场景题一个金融交易系统堆内存32GB要求GC停顿10ms。推荐什么GC开启什么参数代码题配置生产环境G1 GC日志要求输出到/var/log/app-gc.log保留10个文件每个100MB。 你的学习进度当前第62篇 / 共108篇 ·进阶篇JVM调优与故障排查第61~70篇✅ 已完成基础篇44篇 第45~62篇 正在学第62篇⏳ 待学习第63~108篇 完整目录 学习指南 | 订阅本专栏不错过每一篇 下一篇文章预告下一篇《第63篇GC调优实战》内容简介GC日志分析实战、JVM参数调优、年轻代/老年代大小调整、G1/ZGC调参最佳实践、生产环境GC问题排查流程。JVM调优专题持续深入拿下GC调优实战《Java 100 天进阶之路 | 从入门到上岗就业》每天一篇建议收藏 关注一起100天拿offer 点击关注我更新后第一时间收到推送
