Java垃圾回收选对了，性能飙升不是梦！Oracle老炮20年GC实战经验全公开
你是不是还在用默认的垃圾回收器？是不是觉得Java性能上不去就是代码问题？大错特错！垃圾回收器（Garbage Collector，简称GC）选错了，再牛的代码也跑不动。
来自Oracle Java平台组资深工程师Stefan Johansson在一次技术大会上的深度分享。这位老哥干了20年Java平台开发，其中12年专注垃圾回收——说白了，他就是GC界的老炮儿！
他反复强调：Java新版本性能提升巨大，但很多人还在用JDK8死扛；更致命的是，根本没选对适合你业务场景的垃圾回收器。
这篇文章，就带你一口气吃透Java五大GC的差异、G1与ZGC的实战优劣、调优技巧、案例分析，甚至连Stefan亲测的Specjbb 2015压测数据都给你扒出来！看完这篇，你绝对会重新审视你的JVM启动参数！
五大垃圾回收器，到底谁适合你的业务？
Java平台之所以强大，正是因为它能适配从批处理、桌面UI到超大规模云服务的各式场景。而实现这种灵活性的关键，就是——多款垃圾回收器并存！目前OpenJDK内置五大GC：Serial（串行回收器）、Parallel（并行回收器）、G1（Garbage-First）、ZGC（Z垃圾回收器）和Shenandoah（雪兰多）。
别被名字吓到，其实它们各有绝活。
Serial主打极低内存开销，适合小容器或嵌入式场景；
Parallel是吞吐量之王，适合后台批量任务——但万一堆满了，它会直接“世界静止”（Stop-The-World），一次GC可能卡死几秒！
G1自JDK9起成为默认GC，它在吞吐、延迟和内存之间取得精妙平衡，还能把整堆回收拆成多次“混合回收”（Mixed GC），避免恐怖的Full GC。
而ZGC和Shenandoah则是专为超低延迟打造的并发GC，目标就是“GC暂停永远低于1毫秒”，连高频交易系统都能扛！
Oracle官方现在主推G1和ZGC，未来几乎所有场景都将由它们覆盖——Serial和Parallel只留作极少数特殊用途。所以，别再盲目用Parallel了，除非你真的不在乎卡顿！
G1：延迟可控的“全能选手”，十年打磨终成默认王者
G1的目标，就是干掉Parallel那“说停就停”的臭脾气。
它通过“并发标记”在应用运行时收集对象活跃度信息，再分批清理最“垃圾”的区域（所以叫Garbage-First）。你只需要设置一个暂停时间目标（默认200毫秒），G1就会自动调整回收节奏——想更低延迟？把目标设成50毫秒，它就会更频繁但更短地GC；想更高吞吐？调高到300毫秒，让它少打扰你。
这十年，Oracle团队对G1进行了史诗级优化：
JDK11大幅削减原生内存占用；
JDK17加入NUMA支持，提升多核性能；
JDK21起GC暂停异常值大幅收敛；
到JDK25，原生内存开销从JDK8的1.3GB（16GB堆）暴降至440MB！
这意味着G1现在连小容器都能跑得飞起。更疯狂的是，他们正在搞“自动堆大小调整”（Automatic Heap Sizing），以后连-Xmx都不用手动设了！但记住：千万别手动指定年轻代大小（比如-XX:NewRatio），这会锁死G1的智能调度，反而拖垮性能！
ZGC：1毫秒停顿的“延迟杀手”，不止大堆才配用
很多人以为ZGC只适合几十GB的大堆？大错特错！Stefan亲口澄清：只要你的应用分配速率高、又极度怕卡顿，哪怕1GB堆，ZGC也是最佳选择。ZGC自JDK11作为实验特性登场，当时目标只是“10毫秒内”，到JDK17终于实现“亚毫秒级暂停”——实测最差暂停仅200微秒！
JDK21引入分代模式（Generational ZGC）后，吞吐量直接起飞，现在JDK25更是默认开启分代，彻底淘汰旧版。
ZGC的使用简直傻瓜：你基本不用调任何参数，设好堆大小就行（未来连这都不用）。但注意！ZGC用的是共享内存（shared memory），而G1用匿名内存（anonymous memory）——在Linux上，这两者的“大页”（Huge Pages）配置是分开的！
很多Linux发行版默认只给匿名内存开了透明大页，导致ZGC跑不起来性能。所以一定要手动检查/proc/sys/vm/下的配置，确保ZGC也能吃上大页红利（性能提升10%不是梦）！
调优不是玄学！三大核心指标决定GC生死
选GC前，先问自己三个问题：你更看重吞吐量（单位时间处理多少事务）？还是延迟（单次请求响应多快）？或者内存/CPU资源占用（足迹）？这三者永远存在权衡。
比如Parallel吞吐无敌，但延迟爆炸；ZGC延迟如丝般顺滑，却吃更多CPU。
Stefan反复强调：千万别继承祖传JVM参数！很多老项目里的-XX:NewSize或-XX:MaxTenuringThreshold，对G1/ZGC不仅无效，反而有害。
正确姿势是：先用默认参数跑基准测试，再根据监控数据微调。特别提醒：G1要避免Full GC（堆太小导致），ZGC要杜绝分配阻塞（Allocation Stall）——这两种都是性能崩盘信号！而JDK25新出的“紧凑对象头”（Compact Object Headers）功能，能将每个对象头从16字节砍到8字节，堆内存直降10%+，务必加上-XX:+CompactObjectHeader试试！
实战案例1：Specjbb 2015压测——G1 vs ZGC谁更香？
Stefan用行业标准压测工具Specjbb 2015做了对比：16GB堆、固定吞吐量（ZGC最大能力的70%）。
结果超震撼！
G1中位响应时间约2毫秒，但99分位飙到近200毫秒（正好卡在默认200毫秒暂停目标）；
而ZGC的99分位始终压在50毫秒内！
监控数据更揭示真相：
G1平均GC暂停65毫秒，最长164毫秒；
ZGC最长暂停仅104微秒——几乎可忽略。
但代价呢？ZGC的CPU占用高达67%（G1仅50%），原生内存占用近1GB（G1仅440MB）。
所以结论很清晰：如果你能接受百毫秒级延迟（比如后台服务），G1更省资源；但若做实时交易、游戏服务器等，ZGC的超低延迟绝对值回票价！
实战案例2：Cassandra数据库——分代ZGC拯救高负载
第二个案例更贴近真实场景：用分布式数据库Cassandra模拟高并发读写。当客户端数超75时，非分代ZGC直接崩了——因为扛不住分配速率，触发分配阻塞，99分位延迟飙升！
但开启分代模式（-XX:+ZGenerational）后，ZGC轻松支撑275客户端，延迟始终平稳。
而G1呢？默认200毫秒目标下，延迟稳定在200毫秒内；
若手动调成50毫秒目标（-XX:MaxGCPauseMillis=50），延迟立刻改善。
这说明什么？G1调参空间大，但ZGC开箱即巅峰——尤其分代模式后，它真正成了“低延迟+高吞吐”的六边形战士！
监控调优黄金法则：日志+飞行记录器=性能显微镜
光调参不够，你得会看数据！
JVM自带两大神器：GC日志和Java Flight Recorder（JFR）。打GC日志超简单：加个-Xlog:gc*:file=gc.log就行；
想看详细事件，用-Xlog:gc*:file=gc.log。
但真正大杀器是JFR——启动时加-XX:+FlightRecorder，事后用JDK Mission Control或jfr view分析。
Stefan演示了如何用JFR精准定位问题：比如Specjbb测试中，G1那个164毫秒暂停其实发生在压测结束后的报告阶段，根本没影响业务！而ZGC的分配阻塞也是报告阶段触发。
所以，永远以业务指标（如API响应时间）为准，别被GC日志吓到！
升级JDK=免费性能大礼包！别再死守JDK8
Stefan最痛心疾首的呼吁就是：赶紧升级JDK！从JDK8到JDK25，GC性能天翻地覆。
比如G1在JDK8原生内存吃掉1.3GB，JDK25只要440MB；
ZGC从JDK11的“实验品”蜕变成JDK25的“延迟终结者”。
而且新特性如NUMA感知、透明大页支持、紧凑对象头，全都在新版本！别拿“稳定”当借口——Oracle连JDK8都早停服了，你的安全漏洞谁来补？
记住：现代Java应用，JDK17或JDK21才是起点，JDK25才是未来！
未来已来：自动堆大小+线程本地GC，GC将彻底隐形
Oracle团队正在干两件大事：
一是G1和ZGC的“自动堆大小调整”（Automatic Heap Sizing），JVM会根据系统空闲内存自动伸缩堆，彻底告别-Xmx；
二是“线程本地GC”（Thread Local GC），让每个线程能独立回收自己的对象，进一步消灭全局暂停。
这意味着未来的Java应用，GC将完全“隐形”——开发者只需专注业务逻辑，内存管理从此无感。Stefan笑称：我们的终极目标，就是让你永远不用碰GC参数！
总结：三句话选对你的GC
1. 要极致吞吐、不怕卡顿？用Parallel（但真的很少见！）
2. 要平衡吞吐与延迟、长稳服务？G1是默认安全牌，记得调低MaxGCPauseMillis
3. 要亚毫秒延迟、扛高分配速率？ZGC开箱即用，务必开分代模式+配大页！
最后，扔掉祖传参数，升级JDK，用JFR监控，用真实业务指标验证——这才是现代Java性能优化正道！