超大存活对象指单个对象大小超过当前可用Survivor空间，如大数组、长字符串等；JVM通过直接分配到老年代或Minor GC时快速晋升机制绕过Survivor，避免复制开销与担保失败。
新生代复制算法对超大存活对象的处理，核心原则是“绕过 Survivor，直送老年代”，避免在小空间内反复复制、挤占资源或触发担保失败。
什么是超大存活对象
超大存活对象指单个对象大小超过 Eden + 一个 Survivor 区总容量的一半，或更常见的是：大于 当前可用 Survivor 空间。典型如大数组、大缓存、长字符串、序列化数据等。HotSpot 中，这类对象通常被标记为“大对象（Large Object）”，JVM 会启动特殊路径处理。
直接分配到老年代（Promotion on Allocation）
- 新对象创建时，JVM 检测其大小是否超过
-XX:PretenureSizeThreshold（默认 0，即禁用），若启用且对象 ≥ 该阈值，直接在老年代分配，跳过 Eden； - 即使未设阈值，若对象大到无法放入 Eden（比如 Eden 仅 8MB，对象需 12MB），JVM 也会尝试直接在老年代分配，并触发一次 Full GC（若老年代也不足，则 OOM）；
- 这种机制不依赖 GC 触发，属于“分配时决策”，响应快、无复制开销。
Minor GC 期间的快速晋升（Early Promotion）
- 当 Minor GC 执行时，若发现某存活对象太大，放不进目标 Survivor 区（To Space），它不会等待年龄达标，也不会尝试切分——而是立即晋升至老年代；
- 这属于 HandlePromotionFailure 机制的一部分：Survivor 空间不足时，JVM 把溢出对象“担保”进老年代，确保复制过程不中断；
- 日志中可见类似
Desired survivor size 1048576 bytes, new threshold 7 (max 15)后紧接promotion failed或tenured记录，说明有对象已提前入老年代。
避免频繁复制带来的性能冲击
复制算法本就依赖“小对象、高死亡率”的假设。超大对象一旦存活，每次 Minor GC 都要完整复制一次，不仅耗时（带宽压力大），还容易导致 To Space 快速填满、触发连续晋升甚至 Full GC。因此 JVM 主动规避：
- 不给大对象加年龄——它从不进入 Survivor，自然不参与年龄累加；
- 不尝试跨 Survivor 搬移——S0→S1 这类操作对它无效；
- 老年代虽用标记-清除/整理，但能容纳大块连续空间，更适合长期驻留的大对象。
本质上，这不是“复制算法的特例处理”，而是 JVM 在分代设计下，对算法前提条件失效时的主动退让与适配。
