Scavenge算法不支持主动加速晋升，真实晋升由内存压力、Survivor容量瓶颈和动态年龄判定决定；GC日志中“new threshold”才是实际生效阈值，若持续≤2，说明Survivor过小或存活率高，应调大SurvivorRatio或TargetSurvivorRatio；仅当存在明确中间生命周期对象且老年代充足时，才可谨慎降低MaxTenuringThreshold至2或3。
Scavenge 算法本身不支持“主动加速晋升”，它只按规则复制存活对象并翻转空间；所谓“快速晋升”，本质是让对象更早、更确定地离开新生代——这靠的不是调高 MaxTenuringThreshold，而是理解并利用晋升触发的真实条件：内存压力、Survivor容量瓶颈和动态年龄判定机制。
看清真实晋升年龄，别信配置值
GC 日志里的 “new threshold” 才是实际生效的晋升年龄，它由 JVM 每次 Minor GC 后动态计算得出，优先级远高于 -XX:MaxTenuringThreshold。如果日志中频繁出现：
Desired survivor size 1048576 bytes, new threshold 2 (max 15) - age 1: 1250000 bytes, 1250000 total
说明 age 1 的对象已超 Survivor 半区容量（1MB），JVM 立即把所有 age ≥ 1 的对象全部晋升——此时阈值被压到 2，设成 15 完全无效。
- 用
grep "new threshold\|age" gc.log抽取连续多次 GC 的趋势，判断是否长期 ≤ 2 - 若
new threshold稳定在 1 或 2，说明 Survivor 区太小或对象存活率过高，应优先扩容或调小SurvivorRatio
控制 Survivor 空间大小，避免被动早晋升
Survivor 区过小会直接触发“动态年龄判定”，导致大量年轻对象提前进老年代。默认 -XX:SurvivorRatio=8（Eden:S0:S1 = 8:1:1）在多数场景下偏紧。
- 建议起点设为
-XX:SurvivorRatio=6，即 Eden 占 75%，两个 Survivor 各占 12.5% - 观察 GC 日志中 “Desired survivor size” 是否持续接近或超过实际 Survivor 容量（如 1MB vs 1.048MB）
- 若长期打满，可配合
-XX:TargetSurvivorRatio=90提高目标使用率上限，但不可超过 100%——否则仍会触发早晋升
识别真正该“快晋”的对象，再考虑压低阈值
盲目降低 MaxTenuringThreshold 风险很高，仅在一种明确场景下合理：存在大量“短命但跨 2~3 次 GC 才死”的中间生命周期对象，它们反复在 Survivor 区复制，浪费 CPU 和内存带宽。
- 典型例子：RPC 框架中临时组装的 Request/Response 对象，生命周期略长于一次请求，但远未到长期驻留程度
- 压低前必须确认：老年代有足够空闲空间，且 GC 策略（如 G1/CMS）不会因此引发并发失败或退化为 Full GC
- 推荐尝试
-XX:MaxTenuringThreshold=2或=3，而非直接设为 1——保留一次缓冲机会，避免误伤真正短命对象
配合新生代大小与分配节奏，减少晋升扰动
晋升不是孤立事件，它和对象创建速率、Eden 区大小强相关。当 Eden 填得太快，Minor GC 频繁发生，Survivor 来不及清空，自然推高晋升概率。
- 用
-XX:MaxNewSize和-XX:NewRatio合理扩大新生代，降低 Minor GC 频率（但注意不要过大，否则单次 GC STW 时间上升） - 检查代码中是否存在突发性对象分配（如批量解析 JSON、构造大数组），考虑分批处理或复用对象池
- Node.js 场景下可通过
--max-new-space-size=8192（单位 KB）显式增大新生代至 8MB，比默认值（64 位约 16MB 总半区，即 8MB 每区）更可控
