虚拟机防大促老年代溢出靠两层预留机制：一是老年代空间分配担保机制，minor gc前预估晋升量并比对剩余空间，不足则触发full gc或oom；二是cms并发阶段保留8%空间缓冲持续晋升，阈值建议调至80~85以提早介入。
虚拟机为防止大促期间老年代溢出，核心是通过两层预留机制协同防御：空间分配担保机制保障Minor GC安全晋升，CMS并发预留空间缓冲并发阶段的持续晋升压力。
老年代空间分配担保机制：Minor GC前的安全预判
每次Minor GC启动前，JVM会主动估算本次新生代存活对象总量，并与老年代当前最大可用连续空间比对：
- 若老年代剩余空间 ≥ 估算晋升量，直接执行Minor GC，业务无感知
- 若不满足，且-XX:+HandlePromotionFailure启用（默认开启），则触发Full GC腾空间
- 若该参数关闭或Full GC后仍不足，直接抛出java.lang.OutOfMemoryError
该机制本质是“宁可提前停顿，也不让晋升失败”，避免因晋升中断引发不可控异常。
CMS并发阶段的8%预留空间：应对持续晋升的关键缓冲
CMS在并发标记和清理过程中，用户线程仍在运行，新对象持续晋升至老年代。因此它不等老年代填满才行动：
- 默认在老年代使用率达92%时触发CMS GC，强制保留8%空间专供并发阶段晋升
- 该阈值可通过-XX:CMSInitiatingOccupancyFraction=80调低，大促前建议设为80~85，提早介入、扩大缓冲余量
- 若预留不足，发生Concurrent Mode Failure，CMS立即降级为Serial Old，引发秒级STW——这是大促最需规避的场景
配套加固配置：不止靠预留，更要控源头
单靠预留不够，需结合业务流量特征做主动调控：
- 设-XX:NewRatio=3，使年轻代:老年代 = 1:3，增大年轻代容量，减少过早晋升
- 设-XX:PretenureSizeThreshold=1M，避免大对象直接冲击老年代
- 配合监控，确认CMS GC日志中无promotion failed或concurrent mode failure告警
