调整年轻代比例不能彻底规避老年代早衰，因其主因是对象分配与生命周期不匹配；newratio需适配驻留周期而非盲目调大，survivorratio是阻断早衰关键杠杆，且须配合伪短命对象隔离、大对象拦截和晋升行为验证。
调整年轻代前后比例本身不能“彻底规避”老年代早衰，因为老年代早衰（即本该短期存活的对象过早晋升至老年代）根本原因不在比例数字本身，而在于对象分配行为与生命周期管理是否匹配。所谓“前后比例”，实际指 NewRatio（控制年轻代/老年代容量比）和 SurvivorRatio（控制年轻代内 Eden/Survivor 分配），二者协同影响大对象是否被误判、误升、误留。
明确大对象的两种典型路径
真正触发老年代早衰的大对象，往往不是单一大数组，而是高频创建的中等体积对象（如 JSONNode、HashMap$Node、byte[] 缓存、拼接后的长 String），它们：
- 在 Eden 区分配时未超限，逃过 -XX:PretenureSizeThreshold 拦截；
- 因 Survivor 空间不足或年龄阈值过低，在 1~2 轮 Minor GC 后被迫晋升；
- 进入老年代后长期滞留（如 Saga 上下文跨多阶段），加速老年代碎片化与填充速度。
NewRatio 设置要服务于对象驻留周期，而非盲目调大
NewRatio 决定年轻代占堆比例，但关键不是“越大越好”。过大年轻代会导致：
- 单次 Minor GC STW 时间上升，尤其在 G1 或 ZGC 下影响响应敏感型服务；
- Eden 过大 + Survivor 不足 → 更多对象跳过 Survivor 直接晋升（promotion failure）；
- 掩盖代码层问题：比如反复构建全量 DTO、未复用缓冲区等，靠堆硬扛反而延缓根因治理。
建议策略：
- 若监控显示 Minor GC 间隔短于 200ms 且 Eden 几乎每次满，可适度降低 NewRatio（如从 2→1.5），让年轻代占比升至 ~40%，但必须同步检查 Survivor 使用率；
- 若老年代占用率缓慢爬升、Full GC 尚未频繁，但 tenuring distribution 显示大量 age=1 对象晋升，则说明 NewRatio 合理，问题出在 Survivor 容量或对象生命周期建模上。
SurvivorRatio 是阻断早衰的关键杠杆
SurvivorRatio 控制 Eden 与单个 Survivor 区的容量比。默认 8 表示 Eden:S0:S1 = 8:1:1，即 Survivor 合计占年轻代 20%。对分布式事务类应用，这个比例常显不足。
- 当 GC 日志出现 “Desired survivor size XXX > actual YYY” 或 “tenuring threshold = 1”，就是 Survivor 不够的明确信号；
- 将 SurvivorRatio 从 8 降至 4（Eden:S0:S1 = 4:1:1），Survivor 合计占比升至 40%，能显著延缓中生命周期对象晋升；
- 但 SurvivorRatio 不宜低于 3（即 Survivor 占年轻代超 50%），否则 Eden 过小，Minor GC 频次反升，且浪费内存——两块 Survivor 区始终只用其一。
必须配合的三项非参数动作
光调参数无法闭环。以下三件事不做，比例再准也白搭：
- 识别并隔离伪短命对象：把 Saga 流程 ID、状态版本、重试计数等抽为轻量 SagaContext，禁用全局 Map/JSONNode 存储跨阶段数据；
- 拦截真正的大对象：用 -XX:PretenureSizeThreshold=1048576（1MB）强制大 byte[]、大 List 直接进老年代，避免挤爆 Eden 和 Survivor；
- 验证晋升行为：加 -Xlog:gc+age=debug 启动，观察每轮 GC 后各年龄档对象大小分布，确认 age≥4 的对象是否稳定、是否符合业务预期。
