新生代存活对象比例越低，复制算法效率越高；比例超10%会触发担保晋升，增加老年代压力；长期高于15%表明存在“伪长生命周期”对象，需结合GC日志与业务代码排查。

新生代存活对象比例直接决定复制算法的实际效率——比例越低，复制动作越少，GC越快；比例升高，复制开销增大，甚至可能拖慢整个 Minor GC 过程。

存活比例低是复制算法高效的前提

复制算法依赖“绝大多数对象死亡”这一事实。HotSpot 默认设计基于约 90%～99% 的对象在首次 GC 时即消亡。这意味着每次 Minor GC 只需搬运 1%～10% 的存活对象，复制量小、耗时短、无碎片。

• 若实际存活率稳定在 2%～5%，Eden + Survivor 的 8:1:1 划分就能很好匹配，一次 GC 基本不触发担保晋升
• 存活率一旦超过 Survivor 区总容量（比如 >10%），就会迫使部分对象直接进入老年代，增加老年代压力
• 长期高于 15%，说明应用存在大量短期但意外“活久见”的对象（如缓存未及时清理、线程局部变量引用过长），此时复制算法优势被削弱

高存活率会暴露复制算法的硬伤

复制算法本身不处理高存活场景：它必须把所有存活对象实打实搬运一遍。当存活对象变多，不仅复制时间上升，还会因 Survivor 空间不足频繁触发提前晋升，造成老年代快速填满、Full GC 风险上升。

• 例如：某次 Minor GC 后存活对象占 Eden 的 12%，而一个 Survivor 区仅占新生代 10%，超出的 2% 就得走分配担保进老年代
• 若连续多次出现该情况，老年代占用率爬升快，可能提前触发 CMS 或 ZGC 的并发回收，甚至 OOM
• 此时单纯调大 SurvivorRatio（如设为 4）未必有效——Eden 缩小会导致 GC 更频繁，反而加重 STW 时间

如何判断和应对存活率异常

不能只看默认比例是否合理，关键要观察真实 GC 日志中的存活数据。

• 开启 -XX:+PrintGCDetails，关注每次 Minor GC 后 “Desired survivor size” 和 “age” 行，确认实际晋升年龄和 Survivor 使用率
• 若发现大量对象在 age=1 就晋升，说明 Survivor 实际可用空间不足，优先检查对象生命周期是否异常，而非盲目扩容 Survivor
• 结合 -XX:+UseAdaptiveSizePolicy（默认开启），让 JVM 根据历史 GC 数据动态调整 Eden/Survivor 比例，比静态配置更适应流量波动

真正影响效率的不是算法本身，而是对象行为

复制算法效率高低，最终取决于你写的代码里对象“活多久”。一个持有大量临时 byte[] 的工具类、未关闭的流、或缓存未设 TTL，都可能把本该朝生夕死的对象变成“伪长生命周期”，悄悄抬高存活率。

• 排查方向优先落在业务逻辑层：是否有对象被 static 引用、ThreadLocal 泄漏、监听器未注销
• 压测时重点关注 GC 日志中 Survivor 区使用率曲线和晋升量（Promotion），比单纯看吞吐率更能反映新生代健康度
• 必要时用 JFR 或 VisualVM 抓取对象分配热点，定位高存活率对象的创建源头