复制算法提升Survivor区空间利用率的核心是高效回收与合理分配，通过控制对象存活率、优化复制节奏、动态调整区大小来减少碎片和避免提前晋升。
复制算法在新生代 Survivor 区提升空间利用率，核心不是“增加容量”，而是通过高效回收 + 合理分配，减少碎片、避免提前晋升，让有限空间服务更多短期对象。关键在于控制对象存活率、优化复制节奏、动态调整 Survivor 区大小。
控制对象存活时间，降低 Survivor 区压力
Survivor 区空间浪费常源于本该快速死亡的对象“滞留过久”，或长生命周期对象过早进入 Survivor。需从应用层配合：
- 避免在方法内创建大数组、大集合等临时但占用内存多的对象；这类对象可能一次 Minor GC 就升入老年代，绕过 Survivor，反而加剧老年代压力，间接导致 Survivor 配置被迫调小
- 减少不必要的对象引用延长（如静态 Map 缓存未及时清理），防止短命对象被意外“带活”到下一轮 GC
- 对已知生命周期可控的中间对象（如 JSON 解析中的临时 Token），考虑复用对象池（谨慎使用，避免逃逸分析失效）
合理设置 Survivor 区比例与目标年龄
JVM 默认 -XX:SurvivorRatio=8（Eden:S0:S1 = 8:1:1），但实际中常因对象存活率波动导致一个 Survivor 区频繁溢出、另一个空闲。建议：
- 开启 -XX:+UseAdaptiveSizePolicy（默认开启），让 JVM 动态调整 Eden/Survivor 比例——它会基于历史 GC 数据，自动收缩 Eden、扩大 Survivor，若发现大量对象在第 2–3 次 GC 后才晋升
- 观察 -XX:MaxTenuringThreshold 的实际效果（可用 -XX:+PrintGCDetails 验证），若多数对象在 age=2 时晋升，可设 -XX:MaxTenuringThreshold=2，避免在 Survivor 中无谓复制多次
- 不强行固定 SurvivorRatio，除非有稳定压测数据支撑；盲目调大 Survivor 可能导致 Eden 过小，GC 频繁，反而降低吞吐
利用动态年龄判定机制，跳过无效复制
JVM 并非严格按年龄阈值晋升。当某次 GC 后，某个年龄的所有对象总大小 > Survivor 空间一半，JVM 会把 ≥ 该年龄的对象全部提前晋升（-XX:+UseAdaptiveSizePolicy 下自动启用）。这本质是空间换时间的优化：
- 它防止 Survivor 区因少量“高龄残留”占满，导致新存活对象无法放入而被迫直接晋升
- 无需手动干预，但需通过 GC 日志确认是否触发（日志中出现 “age” 行并标出 threshold）
- 若发现频繁因“age 1”就触发批量晋升，说明 Survivor 实际有效容量不足，应优先检查对象存活率是否异常，而非调大 Survivor
监控与验证：用数据驱动调优
空间利用率不能只看“用了多少 MB”，要看“是否因 Survivor 不足导致过早晋升”。重点关注：
- 每次 Minor GC 后，Survivor 区的占用峰值（-XX:+PrintGCDetails 中 “S0” / “S1” 后的数值），持续接近 100% 是风险信号
- 老年代增长速率：若 Minor GC 频繁但老年代缓慢增长，说明 Survivor 工作良好；若 Minor GC 后老年代突增，大概率是 Survivor 溢出导致对象直入老年代
- 使用 jstat -gc
观察 S0C、S1C、S0U、S1U 的变化趋势，比单次快照更有价值
不复杂但容易忽略：复制算法的空间效率，本质是时间局部性与空间局部性的平衡。让对象“该死早死、该活稳活”，Survivor 区自然高效。
