AdaptiveSizePolicy仅动态调整新生代内Eden与Survivor区大小及晋升年龄阈值，不改变NewRatio或年轻代/老年代比例；它默认启用但易导致Survivor过小、对象过早晋升，应关闭并用-Xmn、-XX:SurvivorRatio等固定参数调优。
AdaptiveSizePolicy 不会动态调整年轻代与老年代的比例 —— 它只调整新生代内部的 Eden 与 Survivor 区大小，不碰 NewRatio 或老年代占比。
这是最常被误解的一点：很多人以为开了 -XX:+UseAdaptiveSizePolicy（JDK 8 默认启用），JVM 就能“智能地”把老年代缩、年轻代扩来扛流量。实际并非如此。
AdaptiveSizePolicy 真正调整什么？
它只在新生代范围内做三件事：
- 动态增减
Eden区大小（通过调整SurvivorRatio隐式影响） - 动态缩放两个
Survivor区（S0/S1）的容量 - 调整晋升年龄阈值（
MaxTenuringThreshold），但仅限于“动态年龄判断”逻辑，不改变配置值
它完全不修改 NewRatio，也不直接扩大/缩小年轻代整体大小。年轻代总大小仍由 -Xmn 或 -XX:NewRatio 决定（后者仅在未设 -Xmn 时生效）。
常见错误现象：
- 流量突增后
Young GC更频繁，但jstat -gc显示年轻代总大小没变，只是Eden占比飙升、S0/S1被压缩到几 MB - 日志里出现大量
Premature Promotion（对象因Survivor区太小，一次 GC 就直接进老年代） - 老年代使用率快速上升，
Full GC提前触发 —— 这是AdaptiveSizePolicy“努力降低停顿时间”导致的副作用，不是它想帮你扩容老年代
突发流量下该怎么做？别依赖 AdaptiveSizePolicy
应对突发流量的核心是 控制对象晋升节奏 + 预留缓冲空间，而非指望 JVM 自动重分代际比例：
-
关闭自适应策略（显式禁用干扰）：
-XX:-UseAdaptiveSizePolicy
否则它会在你调参过程中反复覆盖你的Survivor分配，让行为不可预测。 -
固定新生代大小，避免浮动：
-Xmn2g
比用-XX:NewRatio=2更可靠 —— 尤其当堆大小本身受容器内存限制（如 Kubernetesmemory.limit）时，NewRatio可能算出非预期值。 -
手动放大
Survivor区防过早晋升：-XX:SurvivorRatio=6
（默认 8 → Eden 占 80%，改 6 后 Eden 占 ~71%，每个 Survivor 升至 ~14%） 若观察到S0使用率长期 >90%，或 GC 日志有Desired survivor size远低于实际分配，说明 Survivor 太小。 -
设置合理晋升阈值（配合监控）：
-XX:MaxTenuringThreshold=6
避免默认 15（几乎不可能达到），也避免设 0（所有存活对象全进老年代）。6～8 是 Web 类应用较稳的起点。
容器环境特别注意：内存上限 ≠ JVM 堆上限
Kubernetes 中若只设 resources.limits.memory: 4Gi，但 JVM 启动参数没加 -XX:MaxRAMPercentage，JVM 可能按宿主机总内存估算堆大小，导致：
- 实际堆远超容器 limit → OOMKilled
-
AdaptiveSizePolicy在“假大堆”上胡乱缩放 Survivor → 更早晋升
正确做法：
-XX:MaxRAMPercentage=75.0 -XX:+UseContainerSupport并确保 JDK 8u191+ 或 JDK 10+（原生支持容器内存限制）
AdaptiveSizePolicy 的“智能”本质是妥协：它在吞吐、延迟、内存 footprint 三者间找平衡点，而突发流量场景下这三点天然冲突。真正可控的路径，是关掉它的自动干预，用固定参数 + GC 日志反馈 + 压测验证闭环调优。否则你会在凌晨三点盯着 jstat 输出，看着 Survivor 区从 100MB 被缩到 2MB，却不知道是谁动的手。
