Parallel收集器的自适应策略依赖JVM运行时采集Minor GC频率、Survivor使用率、对象存活年龄、各代占用趋势等信号，动态调整Eden大小、Survivor容量和晋升年龄，前提是固定堆大小（-Xms=-Xmx）、禁用冲突GC参数，并以-XX:GCTimeRatio为唯一目标锚点。

Parallel收集器的动态自适应调整策略不是靠人工干预参数来“平衡变量”，而是由JVM在运行时持续观测、建模并自动微调，核心目标是稳定达成预设的吞吐量目标（如GC时间占比≤1%）。

它靠什么做决策

策略启用后（-XX:+UseAdaptiveSizePolicy，Java 8+默认开启），JVM会持续采集以下运行时信号：

• Minor GC频率与每次回收的存活对象量
• Survivor区使用率及是否频繁溢出（导致提前晋升）
• 对象平均存活年龄与晋升速率
• 各代空间的实际占用趋势（Eden used、S0/S1 used、Old used）
• 单次GC停顿时间是否逼近-XX:MaxGCPauseMillis阈值（若设置）

它具体调哪些参数

所有调整均围绕年轻代结构展开，且完全覆盖手动配置——一旦启用自适应，-Xmn、-XX:SurvivorRatio、-XX:InitialTenuringThreshold等参数即失效：

• 动态计算Eden区大小：例如日志中出现PSAdaptiveSizePolicy::compute_eden_space_size，后面跟着具体字节数
• 重分配Survivor容量：根据实际使用率升降S0/S1大小，比如从64MB压到16MB，释放空间给Eden
• 浮动晋升年龄：若发现多数对象在第4次GC后才死亡，就将tenuring threshold从默认15逐步下调至6左右

它如何响应业务变化

策略不是静态校准，而是滚动优化。典型表现包括：

• 批处理任务启动初期对象分配激增 → JVM快速扩大Eden，降低GC频次
• 中间阶段缓存对象长期驻留 → 自动收缩Eden、增大Survivor，减少晋升压力
• 老年代回收压力上升 → 暂缓年轻代扩张，优先保障老年代空间余量
• 检测到大量大对象直入老年代 → 可能尝试上调-XX:PretenureSizeThreshold（仅当未显式禁用时）

它依赖什么前提才能稳住

自适应不是万能的，它需要可预测的运行环境才能建立有效模型：

• -Xms = -Xmx：堆总量固定，避免扩容缩容干扰学习过程
• 不混用其他GC参数：如删掉-XX:+UseConcMarkSweepGC或-XX:+UseG1GC，否则日志中会出现ParNew而非PSYoungGen，策略实际未生效
• 以-XX:GCTimeRatio为唯一目标锚点：设为99即告诉JVM“我要99%时间跑业务”，它据此权衡所有内部调整；避免和-XX:MaxGCPauseMillis共用，二者目标冲突