现代JVM转向超低延迟优先，是内存管理哲学与运行时设计的重构；驱动力来自金融交易等毫秒级响应需求，ZGC和Shenandoah将停顿时间从软约束变为硬性边界。

现代JVM正从“吞吐量优先”转向“超低延迟优先”，这不是简单换一个GC算法，而是整个内存管理哲学和运行时设计逻辑的重构。

核心驱动力：业务场景倒逼架构升级

传统后台系统容忍几百毫秒的GC停顿，但金融交易、实时风控、高频API网关等场景要求端到端响应控制在1–10毫秒内。一次200ms的G1 Full GC可能直接导致订单超时或节点心跳断连。JDK 11起ZGC上线、JDK 12引入Shenandoah，标志着JVM不再把“少停顿”当作优化目标，而是作为基础能力来保障。

关键转变体现在三个层面

• 停顿时间不再是统计目标，而是硬性边界：G1的-XX:MaxGCPauseMillis=200是软约束，JVM只“尽量满足”；而ZGC/Shenandoah默认停顿
• STW（Stop-The-World）范围被极致压缩：G1仍有Evacuation阶段需STW；ZGC仅保留初始标记和最终标记两个极短STW阶段（通常
• 内存管理机制彻底重写：ZGC采用染色指针（Colored Pointers）和加载屏障（Load Barrier），在对象访问路径上做轻量拦截，避免传统写屏障带来的性能损耗；Shenandoah用Brooks Pointer实现转发，绕过全局锁竞争。

配套机制同步进化

低延迟不是靠GC单点突破实现的：

• TLAB优化更激进：默认启用-XX:+UseTLAB，减少Eden区分配锁争用；配合-XX:TLABSize按线程负载动态调优，避免小线程浪费大缓冲区。
• 大对象处理策略前移：通过-XX:PretenureSizeThreshold精准拦截大数组分配，防止其直接进入老年代引发碎片化或意外晋升压力。
• 元数据与类卸载更及时：ZGC支持并发类卸载（Concurrent Class Unloading），避免因ClassMetadata堆积触发额外停顿。

代价与取舍依然存在

超低延迟不是免费的：

• ZGC增加约15%–20%的内存占用（用于染色位和重映射空间）
• Shenandoah在高写入负载下可能因Brooks Pointer间接访问略增CPU开销
• 所有低延迟GC都对CPU资源更敏感——它们依赖多核并发执行，单核机器上反而可能劣于G1