虚拟机应对大促老年代爆仓的核心是“空间分配担保机制”和“CMS并发预留空间”双层设计：前者在Minor GC前预判晋升量并触发Full GC或OOM；后者默认92%触发CMS、预留8%供并发晋升，阈值可调低，配合NewRatio=3和PretenureSizeThreshold=1M等配置加固。
虚拟机为应对大促突发流量导致老年代爆仓，核心是通过“空间分配担保机制”和“CMS并发预留空间”双层设计来缓冲压力。
老年代空间分配担保机制
这是JVM在每次Minor GC前主动做的安全检查。当新生代对象准备晋升时，JVM会估算本次存活对象总量，并与老年代当前最大可用连续空间比对：
- 若老年代剩余空间 ≥ 估算晋升量，直接执行Minor GC，不中断业务
- 若不满足，且启用了-XX:+HandlePromotionFailure（默认开启），则触发Full GC腾空间；否则直接报
java.lang.OutOfMemoryError: GC overhead limit exceeded - 该机制本质是“预判式防御”，避免晋升失败引发的不可控停顿
CMS并发清理阶段的8%预留空间
CMS作为低延迟的老年代回收器，必须在并发标记和并发清理过程中容忍新对象持续晋升。因此它不等老年代彻底满才启动，而是提前行动：
- 默认在老年代使用率达92%时触发CMS GC，保留8%空间专供并发阶段的对象晋升
- 这个阈值可通过-XX:CMSInitiatingOccupancyFraction=85调低（如大促前设为80），让GC更早介入，留出更大缓冲余量
- 若预留不足，发生
Concurrent Mode Failure，JVM将紧急降级为Serial Old，造成秒级STW——这正是大促最需规避的场景
大促前可落地的三项关键配置
仅靠默认策略不够，需结合业务特征主动加固：
-
调低CMS触发阈值：比如设为
-XX:CMSInitiatingOccupancyFraction=75，给突发流量多留20%缓冲带 -
增大老年代初始占比：用
-XX:NewRatio=3（即老年代占堆75%），降低晋升竞争压力 -
限制大对象直入老年代：通过
-XX:PretenureSizeThreshold=1M避免单次分配挤占大量连续空间
