复制算法专为高死亡率对象设计，长生命周期对象反复在Survivor区间搬运却不晋升，导致CPU空耗、STW延长、老年代压力隐性上升；应调低晋升阈值或改用弱引用管理。
复制算法在面对大量长生命周期对象时，确实会陷入一种低效甚至失效的循环——不是因为算法本身出错，而是它被设计用来处理“高死亡率、短存续期”的对象分布，一旦对象长期存活，就会反复在 Survivor 区之间搬运，却不晋升，最终既浪费 CPU 时间，又加剧老年代压力，还掩盖真实内存问题。
为什么长生命周期对象会让复制算法“白搬”
复制算法依赖“对象快速死亡”这一前提：Eden 区满后，只有一小部分对象存活，复制成本低；这些幸存者进入 S0，下一次 GC 若仍存活，就搬到 S1，再下一次又搬回 S0……只要没达到晋升年龄或空间阈值，它们就在 S0/S1 间来回横跳。关键在于：
- 每次 Minor GC 都要扫描并复制这些“钉子户”，哪怕它们已驻留 5 分钟，JVM 仍视其为“新生代待观察对象”
- 它们不触发晋升，不是因为不够老，而是因动态年龄判定未满足（例如 S0 容量大、同龄对象总和未超半），或 MaxTenuringThreshold 被设得过高
- 结果就是：同一组对象被反复复制数十次，GC 日志里看到的是稳定的 “Survivors: 200M→200M”，但 real 时间持续升高——搬的不是数据，是冗余开销
退化成“无限搬迁”的典型信号
这不是理论风险，而是可从运行态直接观测到的现象：
- Minor GC 频率未明显上升，但每次 STW 中 Copy 阶段耗时稳步增长（real=0.18s → 0.25s → 0.33s）
- GC 日志显示 S0/S1 使用率长期高位震荡（如 S0 used 始终 90%+，S1 同样），说明对象“卡”在 Survivor 区出不去
- 老年代内存缓慢但持续上涨，却极少触发 Mixed GC —— 因为 G1 认为“老年代 Region 还没到回收阈值”，而实际是大量长周期对象正安静地挤在 Survivor 里，等待某次突发晋升压垮堆
怎么打破这个循环
核心思路是让该走的对象尽快走，别困在复制路径里：
- 调低 -XX:MaxTenuringThreshold（例如设为 4～6），缩短晋升窗口，避免对象在 Survivor 区无意义滞留
- 启用并合理设置 -XX:+UseAdaptiveSizePolicy，让 JVM 动态调整 Survivor 大小与晋升阈值，应对长周期对象突增
- 检查是否存在本该进老年代的大对象（≥ 512KB 默认阈值），却因分配失败回退到 Eden，引发连锁复制；可通过 -XX:G1HeapRegionSize 和 -XX:G1LargeObjectThresholdPercent 控制
- 若确认业务中确有大量缓存类长生命周期对象，应主动用 WeakReference 或 SoftReference 管理，而非依赖 GC 自动识别
复制算法不是不能处理长生命周期对象，而是它根本不该承担这个任务。把它留在新生代反复搬运，等于让快递员每天把同一箱货从 A 仓搬到 B 仓再搬回 A 仓——车没坏，货没丢，但系统已经瘫痪了。
