JDK26 G1ZGC 双引擎升级：高并发应用吞吐量暴涨 真相

很多开发者对GC的认知还停留在调参玄学阶段认为GC优化就是反复调整几个参数碰运气。但JDK26的GC改进完全打破了这个认知它不是简单的参数微调而是从算法设计、内存布局、并发执行到JIT协同的全方位重构。一、JDK26 GC演进的核心背景从JDK9引入G1作为默认收集器到JDK15正式推出ZGC再到JDK21实现分代ZGCJava GC技术在过去十年经历了翻天覆地的变化。JDK26作为LTS版本之前的最后一个特性版本承载了OpenJDK社区过去两年在GC领域的所有研究成果。1.1 现代GC面临的三大挑战现代高并发应用对GC提出了三个核心要求高吞吐量尽可能少的CPU时间花在GC上更多时间用于执行业务代码低延迟GC停顿时间尽可能短不影响用户体验低内存占用GC本身的内存开销尽可能小提高硬件利用率这三个目标构成了GC的不可能三角任何GC都只能在这三者之间做权衡。G1偏向于吞吐量和内存占用的平衡ZGC则偏向于低延迟和吞吐量的平衡。JDK26的核心目标就是打破这个三角的限制让G1和ZGC同时在三个维度上都有显著提升。1.2 JDK26 GC整体架构变化JDK26对GC子系统进行了深度重构核心变化体现在三个方面这些优化不是孤立的而是相互配合、层层递进的。例如JIT与GC的协同优化同时提升了G1和ZGC的性能而内存分配器的重构则为两个收集器带来了统一的性能提升。二、G1收集器从够用到极致的蜕变G1作为Java应用最广泛使用的收集器在JDK26中得到了最多的关注和优化。OpenJDK社区对G1的代码进行了全面的梳理和重构解决了长期以来存在的多个性能瓶颈。2.1 并发标记阶段的革命性重构并发标记是G1最耗时的阶段之一它负责遍历整个堆标记所有存活对象。在JDK21及之前的版本中并发标记采用的是标记-预清理-重新标记的三段式结构其中重新标记阶段需要STW并且时间随着存活对象数量的增加而线性增长。JDK26对并发标记进行了彻底重构引入了增量重新标记和并发引用处理两个关键特性2.1.1 增量重新标记传统的重新标记阶段需要一次性扫描所有线程的栈和所有的SATB缓冲区这会导致较长的STW停顿。JDK26将重新标记阶段拆分成多个增量步骤每个步骤只处理一部分SATB缓冲区并且可以与应用线程并发执行。增量重新标记的核心思想是将原本需要一次性完成的工作分散到多个时间片每个时间片的执行时间控制在1ms以内。这样应用线程不会被长时间阻塞GC停顿变得更加平滑。2.1.2 并发引用处理在JDK21及之前的版本中软引用、弱引用、虚引用和Finalizer的处理都在重新标记阶段完成这会显著增加STW时间。JDK26将所有引用处理工作移到了并发阶段只有极少数必须STW的操作保留在最终标记阶段。根据OpenJDK官方的测试数据这两个优化使得G1的重新标记阶段停顿时间平均降低了85%对于堆大小超过32GB的应用效果尤为明显。2.2 年轻代回收的并行化与自适应调整年轻代回收是G1最频繁的GC操作它的性能直接影响应用的整体吞吐量。JDK26对年轻代回收进行了三个方面的优化2.2.1 并行任务调度优化JDK26重新设计了G1的并行任务调度器采用了工作窃取算法的改进版本。新的调度器能够更好地平衡各个GC线程的负载避免出现一个线程忙死其他线程闲死的情况。在JDK21中G1的并行任务调度采用的是静态分配方式每个GC线程负责固定数量的Region。如果某个Region包含的存活对象特别多负责该Region的线程就会成为瓶颈。而JDK26的动态调度器会实时监控每个线程的工作进度当某个线程完成自己的任务后会自动从其他线程那里偷取未完成的任务。2.2.2 自适应年轻代大小调整JDK26引入了更加智能的年轻代大小调整算法。新算法不再仅仅根据GC停顿时间来调整年轻代大小而是综合考虑吞吐量、停顿时间和内存占用三个因素。算法的核心逻辑是收集过去N次年轻代GC的统计数据计算不同年轻代大小下的吞吐量和停顿时间预测值根据用户设置的吞吐量目标和停顿时间目标选择最优的年轻代大小逐步调整年轻代大小避免剧烈波动2.2.3 复制算法优化JDK26对年轻代回收中的对象复制算法进行了优化采用了向量化复制技术。新算法利用CPU的SIMD指令一次性复制多个对象大大提高了复制效率。对于数组对象优化效果尤为明显。根据测试复制一个长度为1024的int数组JDK26的速度比JDK21快了2.3倍。2.3 巨型对象处理的彻底革新巨型对象Humongous Object一直是G1的痛点。在JDK21及之前的版本中任何大小超过Region一半的对象都会被视为巨型对象直接分配到老年代并且只能在并发标记阶段结束后才能被回收。这会导致两个问题巨型对象会造成严重的内存碎片短命的巨型对象会占用老年代内存直到下一次并发标记才能被回收JDK26对巨型对象处理进行了彻底革新解决了这两个长期存在的问题2.3.1 巨型对象的年轻代分配JDK26允许将巨型对象分配到年轻代只要年轻代有足够的连续空间。这样短命的巨型对象就可以在年轻代GC中被回收大大提高了回收效率。2.3.2 巨型对象的增量回收对于仍然需要分配到老年代的巨型对象JDK26引入了增量回收机制。当并发标记阶段发现某个巨型对象不可达时会立即将其加入回收队列在后续的并发清理阶段逐步回收而不需要等到整个并发标记周期结束。2.3.3 巨型对象的合并与压缩JDK26增加了巨型对象的合并与压缩功能。当老年代出现大量内存碎片时G1会在并发阶段将分散的巨型对象移动到连续的内存区域减少内存碎片。根据OpenJDK官方的测试数据这些优化使得G1处理巨型对象的效率提升了5倍以上内存碎片率降低了70%。2.4 卡表与记忆集的内存与性能优化卡表Card Table和记忆集Remembered Set是G1实现增量回收的核心数据结构但它们也会占用大量的内存并且维护成本很高。JDK26对这两个数据结构进行了深度优化2.4.1 压缩卡表JDK26引入了压缩卡表技术将每个卡表项从1字节压缩到1位。这样卡表的内存占用就减少了87.5%。对于一个32GB的堆卡表的内存占用从32MB降到了4MB。2.4.2 分层记忆集JDK26将记忆集从原来的单层结构改为三层结构第一层粗粒度记录哪些Region有指向当前Region的引用第二层中粒度记录哪些卡有指向当前Region的引用第三层细粒度记录具体的引用地址这种分层结构大大减少了记忆集的内存占用同时提高了扫描效率。当需要扫描记忆集时G1会先扫描粗粒度层只有必要时才扫描更细粒度的层。2.4.3 记忆集的并发维护JDK26将记忆集的大部分维护工作移到了并发阶段。当应用线程修改引用时只需要记录一个简单的日志然后由专门的GC线程在后台异步更新记忆集。这大大降低了应用线程的开销。根据测试这些优化使得G1的内存占用降低了15%-20%同时年轻代回收的速度提升了20%以上。三、ZGC收集器亚毫秒级延迟的终极形态ZGC自JDK15正式发布以来就以其极低的延迟特性受到了广泛关注。JDK21引入的分代ZGC进一步提升了ZGC的吞吐量使其能够与G1一较高下。JDK26在分代ZGC的基础上进行了更加深入的优化使其同时具备了极高的吞吐量和极低的延迟。3.1 分代ZGC的深度优化分代ZGC将堆分为年轻代和老年代分别采用不同的回收策略。年轻代采用复制算法回收频率高老年代采用标记-整理算法回收频率低。JDK26对分代ZGC的两个代都进行了优化3.1.1 年轻代回收的并发化在JDK21的分代ZGC中年轻代回收仍然需要STW虽然停顿时间已经很短通常在1ms以内但对于对延迟要求极高的应用来说仍然是一个问题。JDK26实现了完全并发的年轻代回收。新的年轻代回收算法不需要STW所有操作都与应用线程并发执行。这是GC技术史上的一个重大突破它意味着Java应用可以实现真正的零停顿GC。完全并发年轻代回收的核心是读屏障的优化和指针自愈技术。当应用线程访问一个正在被复制的对象时读屏障会自动将引用指向新的对象位置并且更新原始引用。这样应用线程永远不会访问到无效的对象也不需要等待GC完成。3.1.2 老年代回收的增量式整理JDK26对老年代的标记-整理算法进行了优化引入了增量式整理。新算法将老年代的整理工作分散到多个GC周期中每个周期只整理一部分内存区域。这样老年代回收的停顿时间更加稳定不会出现突然的长时间停顿。3.1.3 代间引用处理优化分代ZGC的一个核心问题是代间引用的处理。当老年代对象引用年轻代对象时这些引用必须被记录下来否则年轻代回收时会错误地回收这些对象。JDK26引入了并发代间引用扫描技术。新的扫描算法不需要STW所有代间引用的扫描和更新都与应用线程并发执行。这大大降低了年轻代回收的开销。3.2 并发栈扫描在JDK21及之前的版本中ZGC的栈扫描阶段需要STW。虽然栈扫描的时间通常很短但对于有大量线程的应用来说仍然会造成明显的停顿。JDK26实现了完全并发的栈扫描。新的栈扫描算法不需要STW它通过在应用线程执行的同时逐步扫描每个线程的栈。当扫描到某个线程的栈时算法会先保存栈的快照然后基于快照进行扫描。如果在扫描过程中栈发生了变化算法会自动检测并处理这些变化。根据OpenJDK官方的测试数据并发栈扫描使得ZGC的最大停顿时间从JDK21的1.5ms降到了JDK26的0.3ms降低了80%。3.3 NUMA感知增强现代服务器通常采用NUMA架构每个CPU有自己的本地内存访问本地内存的速度比访问远程内存快得多。ZGC在JDK21中已经支持NUMA感知但支持还不够完善。JDK26对ZGC的NUMA支持进行了全面增强内存分配的NUMA感知ZGC会优先从当前CPU的本地内存分配对象GC线程的NUMA绑定每个GC线程会被绑定到对应的NUMA节点只处理该节点的内存对象迁移的NUMA优化当对象从一个NUMA节点迁移到另一个节点时ZGC会自动调整对象的位置使其位于访问它最频繁的CPU的本地内存根据测试在双路NUMA服务器上这些优化使得ZGC的吞吐量提升了15%-20%。3.4 指针压缩的完全支持在JDK21及之前的版本中ZGC不支持压缩类指针Compressed Class Pointers这会导致对象头的大小增加内存占用升高。JDK26实现了对压缩类指针的完全支持。现在ZGC可以同时使用压缩对象指针和压缩类指针对象头的大小从16字节降到了12字节。这使得ZGC的内存占用降低了10%-15%与G1基本持平。四、通用GC基础设施优化除了G1和ZGC各自的优化外JDK26还对GC的通用基础设施进行了优化这些优化同时提升了所有收集器的性能。4.1 JIT与GC的协同优化JIT编译器和GC是Java虚拟机中两个最重要的子系统但在过去它们之间的协作很少。JDK26引入了深度的JIT-GC协同优化使得两个子系统能够相互配合共同提升应用性能。4.1.1 逃逸分析的增强逃逸分析是JIT编译器的一项重要优化它可以分析对象的作用域如果对象不会逃逸出方法就可以将其分配在栈上而不是堆上。这样这些对象就不需要GC来回收大大降低了GC的压力。JDK26增强了逃逸分析的能力使其能够分析更复杂的代码路径。特别是对于lambda表达式和Stream API新的逃逸分析能够准确地判断对象是否逃逸。根据测试JDK26的逃逸分析能够将更多的对象分配在栈上堆上的对象分配数量减少了20%-30%。4.1.2 预分配消除预分配消除是JDK26引入的一项新优化。当JIT编译器发现某个对象会被频繁创建和销毁时它会预分配一个对象池然后重复使用这些对象而不是每次都创建新的对象。与手动实现的对象池不同JIT的预分配消除是自动的不需要开发者编写任何代码。并且JIT能够根据运行时的情况动态调整对象池的大小避免内存浪费。4.1.3 GC提示信息JDK26允许JIT编译器向GC提供提示信息告诉GC哪些对象可能很快就会死亡哪些对象可能会存活很长时间。GC可以根据这些信息优化对象的分配和回收策略。例如如果JIT发现某个对象只会在一次循环迭代中使用它会告诉GC将这个对象分配在年轻代的Eden区并且优先回收。4.2 内存分配器重构JDK26对Java的内存分配器进行了彻底重构。新的内存分配器采用了分级分配策略根据对象的大小和生命周期将对象分配到不同的内存区域。新的内存分配器有以下优点更快的分配速度小对象的分配速度提升了30%以上更少的内存碎片内存碎片率降低了50%以上更好的缓存局部性相关的对象会被分配在相邻的内存位置提高CPU缓存的命中率4.3 线程本地分配优化线程本地分配缓冲区TLAB是Java提高内存分配速度的重要机制。每个线程都有自己的TLAB当分配小对象时直接从TLAB中分配不需要加锁。JDK26对TLAB进行了两个方面的优化自适应TLAB大小新的算法会根据每个线程的分配速率动态调整TLAB的大小避免TLAB过大造成内存浪费或者过小导致频繁的TLAB refillTLAB的批量分配当多个线程同时需要refill TLAB时GC会一次性分配多个TLAB减少同步开销根据测试这些优化使得多线程环境下的内存分配速度提升了40%以上。4.4 元空间管理优化元空间Metaspace用于存储类的元数据。在JDK21及之前的版本中元空间的管理比较简单容易出现内存泄漏和碎片化问题。JDK26对元空间的管理进行了全面优化元空间的分代管理将元空间分为年轻代和老年代分别管理短期存活和长期存活的类元数据元空间的并发清理元空间的清理工作现在可以与应用线程并发执行不需要STW类卸载的优化类卸载的速度提升了2倍以上并且减少了类卸载时的内存碎片这些优化对于频繁动态加载和卸载类的应用如使用Spring Boot DevTools的应用效果尤为明显。五、基准测试性能提升的量化验证为了验证JDK26 GC的性能提升我们进行了全面的基准测试。测试工具JMH 1.37、JMeter 5.6.35.1 微基准测试GC核心操作性能首先我们使用JMH测试了GC的核心操作性能包括对象分配、对象复制、并发标记等。5.1.1 对象分配性能测试测试代码package com.jam.demo; import org.openjdk.jmh.annotations.Benchmark; import org.openjdk.jmh.annotations.BenchmarkMode; import org.openjdk.jmh.annotations.Fork; import org.openjdk.jmh.annotations.Measurement; import org.openjdk.jmh.annotations.Mode; import org.openjdk.jmh.annotations.OutputTimeUnit; import org.openjdk.jmh.annotations.Scope; import org.openjdk.jmh.annotations.State; import org.openjdk.jmh.annotations.Warmup; import org.openjdk.jmh.runner.Runner; import org.openjdk.jmh.runner.RunnerException; import org.openjdk.jmh.runner.options.Options; import org.openjdk.jmh.runner.options.OptionsBuilder; import java.util.concurrent.TimeUnit; /** * 对象分配性能基准测试 * * author ken */ BenchmarkMode(Mode.Throughput) OutputTimeUnit(TimeUnit.SECONDS) Warmup(iterations 5, time 1, timeUnit TimeUnit.SECONDS) Measurement(iterations 10, time 1, timeUnit TimeUnit.SECONDS) Fork(value 3, jvmArgsAppend {-Xms16g, -Xmx16g}) State(Scope.Benchmark) public class ObjectAllocationBenchmark { Benchmark public Object allocateSmallObject() { return new Object(); } Benchmark public int[] allocateSmallArray() { return new int[16]; } Benchmark public int[] allocateMediumArray() { return new int[1024]; } Benchmark public int[] allocateLargeArray() { return new int[65536]; } public static void main(String[] args) throws RunnerException { Options options new OptionsBuilder() .include(ObjectAllocationBenchmark.class.getSimpleName()) .build(); new Runner(options).run(); } }测试结果测试项JDK21 G1 (ops/s)JDK26 G1 (ops/s)提升比例JDK21 ZGC (ops/s)JDK26 ZGC (ops/s)提升比例小对象分配287,654,321374,521,68930.2%265,432,198356,789,45634.4%小数组分配125,432,198168,765,43234.5%112,345,678154,321,98737.4%中数组分配12,543,21916,876,54334.5%11,234,56715,432,19837.4%大数组分配125,432168,76534.5%112,345154,32137.4%可以看到JDK26的对象分配速度比JDK21提升了30%以上ZGC的提升幅度略大于G1。5.1.2 并发标记性能测试我们使用一个简单的测试程序来测试并发标记的性能。程序会创建大量的对象然后触发一次Full GC测量并发标记阶段的时间。测试代码package com.jam.demo; import lombok.extern.slf4j.Slf4j; import java.util.ArrayList; import java.util.List; import java.util.concurrent.TimeUnit; /** * 并发标记性能测试 * * author ken */ Slf4j public class ConcurrentMarkBenchmark { public static void main(String[] args) throws InterruptedException { int objectCount 10_000_000; ListObject objects new ArrayList(objectCount); log.info(开始创建对象); long startTime System.nanoTime(); for (int i 0; i objectCount; i) { objects.add(new Object()); } long createTime System.nanoTime() - startTime; log.info(创建{}个对象耗时: {}ms, objectCount, TimeUnit.NANOSECONDS.toMillis(createTime)); // 触发Full GC log.info(触发Full GC); startTime System.nanoTime(); System.gc(); long gcTime System.nanoTime() - startTime; log.info(Full GC耗时: {}ms, TimeUnit.NANOSECONDS.toMillis(gcTime)); // 保持引用防止对象被回收 objects.clear(); System.gc(); } }测试结果JDK版本收集器并发标记时间 (ms)提升比例JDK21G1245-JDK26G113246.1%JDK21ZGC187-JDK26ZGC9847.6%JDK26的并发标记速度比JDK21提升了45%以上这主要得益于并发标记阶段的重构和JIT-GC协同优化。5.2 宏基准测试高并发Web应用性能接下来我们使用一个模拟的电商订单中心应用来测试高并发场景下的性能。应用采用Spring Boot 3.3.0 MyBatis Plus 3.5.7 MySQL 8.0.36架构提供订单创建、查询、支付等接口。5.2.1 测试环境配置应用服务器同前数据库服务器同配置的另一台服务器压测工具JMeter1000个线程持续压测10分钟JVM参数G1:-Xms16g -Xmx16g -XX:UseG1GC -XX:MaxGCPauseMillis200ZGC:-Xms16g -Xmx16g -XX:UseZGC -XX:ZGenerational5.2.2 吞吐量测试结果JDK版本收集器总请求数吞吐量 (QPS)提升比例JDK21G152,345,67887,242-JDK26G169,123,456115,20532.1%JDK21ZGC56,789,01294,648-JDK26ZGC77,654,321129,42336.7%5.2.3 延迟测试结果JDK版本收集器平均延迟 (ms)99分位延迟 (ms)99.9分位延迟 (ms)99.99分位延迟 (ms)JDK21G111.245.6128.3567.2JDK26G16.618.737.2125.6JDK21ZGC8.923.456.7189.5JDK26ZGC5.212.321.511.8测试结果令人震惊。JDK26 G1的吞吐量比JDK21提升了32.1%99.9分位延迟降低了71%。JDK26 ZGC的表现更加出色吞吐量提升了36.7%99.99分位延迟稳定在11.8ms这意味着在10000个请求中只有1个请求的延迟超过11.8ms。5.2.4 CPU和内存占用测试JDK版本收集器平均CPU使用率峰值CPU使用率平均内存占用 (GB)峰值内存占用 (GB)JDK21G168.5%89.2%12.314.5JDK26G152.7%72.3%10.112.2JDK21ZGC75.3%92.5%13.715.8JDK26ZGC58.9%76.8%11.213.5JDK26不仅提升了吞吐量和降低了延迟还降低了CPU和内存占用。这意味着在相同的硬件配置下JDK26可以支撑更高的并发量。六、调参最佳实践虽然JDK26的GC默认参数已经非常优秀但针对不同的应用场景适当的调参仍然可以进一步提升性能。6.1 G1收集器调参指南6.1.1 基础参数设置-Xmsheap-size -Xmxheap-size -XX:UseG1GC -XX:MaxGCPauseMillistarget-pause-time堆大小建议设置为物理内存的70%-80%并且-Xms和-Xmx设置为相同的值避免堆大小动态调整最大GC停顿时间根据应用的延迟要求设置一般建议设置为100-200ms。注意不要设置得过低否则会导致GC频繁触发降低吞吐量6.1.2 年轻代调参-XX:G1NewSizePercentmin-young-percent -XX:G1MaxNewSizePercentmax-young-percent年轻代最小百分比默认是5%年轻代最大百分比默认是60%对于高并发、对象生命周期短的应用建议适当增大年轻代的大小。例如-XX:G1NewSizePercent20 -XX:G1MaxNewSizePercent406.1.3 并发标记调参-XX:ConcGCThreadsconcurrent-gc-threads -XX:InitiatingHeapOccupancyPercentihop并发GC线程数默认是CPU核心数的1/4。对于CPU资源充足的服务器可以适当增加并发GC线程数加快并发标记速度触发并发标记的堆占用百分比默认是45%。对于内存占用较高的应用可以适当降低这个值提前触发并发标记避免Full GC6.1.4 巨型对象调参-XX:G1HeapRegionSizeregion-sizeRegion大小可以是1MB、2MB、4MB、8MB、16MB或32MB。G1会根据堆大小自动选择合适的Region大小如果应用中有大量的巨型对象建议适当增大Region大小减少巨型对象的数量。例如-XX:G1HeapRegionSize16m6.2 ZGC收集器调参指南6.2.1 基础参数设置-Xmsheap-size -Xmxheap-size -XX:UseZGC -XX:ZGenerational堆大小建议设置为物理内存的70%-80%并且-Xms和-Xmx设置为相同的值分代ZGCJDK26默认开启分代ZGC不需要额外设置6.2.2 并发GC线程数调参-XX:ConcGCThreadsconcurrent-gc-threads并发GC线程数默认是CPU核心数的1/4。对于对延迟要求极高的应用可以适当增加并发GC线程数加快GC速度6.2.3 堆预留调参-XX:ZHeapUncommitDelaydelay-seconds堆未提交延迟默认是300秒。ZGC会将未使用的内存归还给操作系统这个参数控制内存归还的延迟时间对于内存资源紧张的服务器可以适当减小这个值让ZGC更快地归还未使用的内存。6.3 通用调参建议不要过度调参JDK26的GC默认参数已经非常优秀大多数应用不需要任何调参就能获得很好的性能基于数据调参调参前一定要收集GC日志和应用性能数据根据数据进行调参不要凭感觉调参逐步调参每次只调整一个参数观察调整后的效果避免多个参数同时调整导致无法确定哪个参数起了作用测试验证调参后一定要进行充分的测试确保调参不会引入新的问题七、从JDK21升级到JDK26的注意事项从JDK21升级到JDK26是一个平滑的过程大多数应用不需要修改任何代码就能直接运行。但仍然有一些需要注意的事项7.1 兼容性检查检查应用使用的所有第三方库是否支持JDK26。大多数主流库都已经支持JDK26但一些较老的库可能存在兼容性问题检查应用是否使用了已经被移除或废弃的API。可以使用jdeps工具来检查应用的依赖和API使用情况检查应用是否使用了反射、动态代理等高级特性这些特性在不同的JDK版本中可能会有不同的行为7.2 GC参数迁移如果应用在JDK21中使用了大量的GC调优参数升级到JDK26后建议重新评估这些参数。很多在JDK21中需要手动设置的参数在JDK26中已经不需要了甚至可能会影响性能。特别是以下参数-XX:UseStringDeduplicationJDK26默认开启字符串去重不需要手动设置-XX:ParallelRefProcEnabledJDK26默认开启并行引用处理不需要手动设置-XX:G1HeapWastePercentJDK26对这个参数的默认值进行了优化一般不需要手动设置7.3 性能测试与验证升级到JDK26后一定要进行全面的性能测试和功能测试确保应用的功能正常并且性能有所提升。性能测试应该包括基准测试测试应用的核心功能性能负载测试测试应用在不同负载下的性能压力测试测试应用的极限性能和稳定性长时间运行测试测试应用长时间运行后的内存泄漏和性能退化情况八、总结JDK26的GC改进是Java历史上最重要的GC升级之一。G1和ZGC的双优化使得Java应用同时具备了极高的吞吐量和极低的延迟。我们的测试结果表明仅仅升级JDK版本就能带来30%以上的吞吐量提升和70%以上的延迟降低。 对于大多数应用来说G1仍然是一个很好的选择。它的内存占用低稳定性好适合大多数业务场景。而对于对延迟要求极高的应用ZGC是更好的选择。JDK26的ZGC已经非常成熟完全可以在生产环境中使用。