ZGC中SoftMaxHeapSize参数实际作用与配置相关问题咨询

以下内容基于OpenJDK 17及以上版本的ZGC实现，其他垃圾回收器或旧版本JDK逻辑存在差异

问题1：该参数是否仅会调整ZCollectionInterval和ZUncommitDelay的取值？如果是，具体会调整为多少？ #

该参数不会直接修改这两个配置的取值，触发软上限后ZGC仅会调整这两个规则的执行时机，调整逻辑如下：

• 针对ZCollectionInterval：默认值为0，代表默认仅按内存分配速率触发GC。触发软上限后会立即触发一次并发GC，无需等到配置的间隔时间，不会修改参数本身的配置值。
• 针对ZUncommitDelay：默认值为300秒，代表内存页空闲300秒后才会归还操作系统。触发软上限后，未使用的内存页会被直接标记为可归还，无需等待延迟时间，同样不会修改参数本身的配置值。

问题2：除调整上述两个参数的执行逻辑外，是否还有其他额外处理逻辑？ #

存在额外处理逻辑，核心包括：

• 内存分配限流：如果GC完成后堆内存仍然超过软上限，新的内存分配请求会被限流，小部分分配请求会被强制进入同步等待GC完成的逻辑，避免堆内存快速冲高到-Xmx硬上限。
• 软引用回收策略调整：会比常规状态更激进地回收软引用对象，尽可能释放空闲内存。
• 大对象分配优化调整：超过软上限后，1MB以上的大对象分配会优先尝试复用已释放的大对象内存页，不会直接申请新的物理内存。

问题3：触发软上限后会产生多少额外的CPU开销？ #

开销和堆内存实际水位直接相关：

• 如果GC后堆内存可以降到软上限以下，额外CPU开销仅为多触发1_{2次并发GC的开销，通常占总CPU的2%}5%。
• 如果GC后堆内存长期高于软上限，会额外增加内存分配限流的调度开销、更频繁的软引用扫描开销，极端情况（堆内存接近-Xmx硬上限）下，额外CPU开销会上涨到总CPU的10%~20%。

问题4：如果配置-XX:SoftMaxHeapSize=1M -Xmx=1T这类参数，应用能否正常运行？ #

功能层面可以正常运行，不会出现启动失败或OOM（只要对象总大小不超过1T硬上限），但性能层面完全不可用，不建议任何场景使用该类配置：
1M的软上限会导致ZGC几乎持续处于并发GC状态，绝大多数内存分配请求都会被限流，应用吞吐量会降到正常配置的10%以下，请求延迟也会上涨数十倍。

内容的提问来源于stack exchange，提问作者Aleksandr Dubinsky