g1 通过 -xx:g1reservepercent 预留老年代空间，核心目的是防止并发标记未完成时老年代被填满，从而避免晋升失败或 full gc；该预留是动态保护机制，非静态锁定，需结合停顿目标与晋升速率联动调优。
G1 通过 -XX:G1ReservePercent 预留一部分老年代空间，核心目的不是防“老年代满了”，而是防“并发标记还没做完，老年代就先被填满”，从而避免退化为 Full GC 或触发并发模式失败。
它防的是“标记跟不上晋升”的时间差
并发标记（Concurrent Marking）需要一定时间完成。在这期间，年轻代持续回收，大量存活对象仍会不断晋升到老年代。如果老年代剩余空间太紧，哪怕尚未达到绝对阈值，也可能在标记结束前就被耗尽——这时 G1 没法安全完成晋升，只能中止并发流程，升级为 Stop-The-World 的 Full GC。
预留的这部分内存（默认 10%）就是给标记过程争取缓冲窗口，确保在标记完成前，总有连续空间能容纳新晋升对象。
预留空间不是静态保留，而是动态保护
G1ReservePercent 不是固定划出一块区域锁死不用；它反映的是老年代中“必须保持空闲”的最小比例。G1 会在每次 Mixed GC 或并发周期启动前评估：当前老年代已用空间 + 预估本轮晋升量 ≤ 堆总大小 × (1 − G1ReservePercent)？不满足就提前触发标记或调整回收节奏。
- 若业务晋升速率高（如大促下单峰值），标记压力大 → 需提高 ReservePercent（如 15～20）
- 若对象生命周期短、晋升少（如实时流处理），标记轻松跟上 → 5～10 足够，避免浪费空间
调高参数反而可能加速老年代压力
设为 20%，意味着堆中约 20% 的容量永远不能用于长期对象存储。这带来两个实际影响：
- 老年代可用空间变小 → 并发标记周期更早被触发，Mixed GC 更频繁
- 真正能存稳定对象的空间被压缩 → 同样业务负载下，老年代实际占用率上升更快，形成恶性循环
尤其在容器环境（如 8G 内存 Pod 中设 10G 堆 + 20% reserve），预留空间可能直接挤占 OS 可用内存，引发 OOM Killer 杀进程。
怎么判断是否该调这个值？看日志信号
不要凭感觉调参，重点关注 GC 日志中的两类线索：
- 出现 Promotion Failed 或 to-space exhausted → 预留明显不足，需适当上调
- 并发标记（Concurrent Cycle）频繁提前启动，且伴随 G1Ergonomics 提示“initiating concurrent cycle due to old gen occupancy” → 预留过高或老年代增长过快，应结合晋升量分析
真正有效的调优，是把 G1ReservePercent 和 -XX:MaxGCPauseMillis、-XX:G1HeapRegionSize 联动来看：停顿目标越严，单次回收 Region 越少，老年代释放越慢，就越依赖 ReservePercent 缓冲。
