G1ReservePercent是G1GC中控制预留内存比例的参数（默认10%），用于防止年轻代回收时因老年代无足够连续空间容纳晋升对象而触发to-space exhausted，进而导致并发模式失败或Full GC。
什么是 G1ReservePercent，它防的到底是什么？
G1ReservePercent 是 G1GC 中一个容易被忽略但极其关键的参数，它控制的是“预留内存比例”，默认值为 10%。它的作用不是给应用预留空间，而是给 GC 回收过程本身留出缓冲区，防止在年轻代回收（Evacuation）时，因老年代没有足够连续空间容纳晋升对象，触发 to-space exhausted 错误 —— 这就是典型的“晋升失败”。
晋升失败不是一次普通的 GC 失败，它会直接导致：
- 当前 Young GC 升级为 Full GC 或并发模式失败（Concurrent Mode Failure）
- 停顿时间从几十毫秒飙升至数百毫秒甚至秒级
- 老年代碎片加剧，后续更容易再次失败
它防的不是“内存不够用”，而是“GC 执行时没地方搬对象”。
为什么设高了反而让堆更“吃紧”？
G1ReservePercent 的数值是按当前堆总容量动态计算的。比如堆设为 -Xmx10g，-XX:G1ReservePercent=15，那 G1 就会强制保留约 1.5G 内存不参与任何对象分配或晋升 —— 这部分内存始终处于“可用但不可用”状态。
常见误操作：
- 看到频繁
to-space exhausted，就盲目把G1ReservePercent从 10 调到 20，结果发现老年代实际可用空间锐减，Old GC 频率反而上升 - 在容器化环境（如 8G 内存 Pod）里仍用 12G 堆 + 15% reserve，OS 层 OOM Killer 直接干掉进程
本质矛盾：预留越多，晋升失败风险越低；但堆有效利用率越差，老年代压力越大，可能提前触发并发标记甚至 Full GC。
怎么定一个合理的值？看这三个信号
判断 G1ReservePercent 是否合适，不能只看参数，得盯 GC 日志里的行为反馈：
重点关注日志中是否出现以下字段：
-
to-space exhausted：必须加，建议立刻 +5（如 10→15），但不超过 20 -
Concurrent Cycle Initiated后紧跟Concurrent Mode Failure：说明并发标记来不及完成，reserve 不足或InitiatingHeapOccupancyPercent设太高，需同步调低后者或加 reserve - 老年代长期稳定在 70%~85% 占用，且无晋升失败，但
Old区增长缓慢 → reserve 可能偏高，尝试从 15 降到 12，观察一周
生产经验参考：
- 电商下单类（短生命周期+突发流量）：12~15%
- 实时计算/流处理（对象存活久、晋升多）：10~12%
- 数据导出服务（偶发大对象、Humongous 区多）：15%，并配合
-XX:G1HeapRegionSize=4m减少跨 Region 大对象
和 InitiatingHeapOccupancyPercent 的联动关系
G1ReservePercent 和 InitiatingHeapOccupancyPercent（简称 IHOP）是一对咬合齿轮：IHOP 决定“什么时候开始打扫仓库”，reserve 决定“打扫时腾出多少临时周转区”。
典型错误配置：
- IHOP=45 + G1ReservePercent=5：并发标记启动太早，但预留太少 → 标记未完，晋升已塞满 → 并发模式失败
- IHOP=70 + G1ReservePercent=15：标记启动太晚，老年代已逼近极限，reserve 再高也救不了 → 一样触发失败
推荐组合策略：
- 若业务对象晋升率高（Young GC 后老年代增长快），优先调低 IHOP（40~45），再适度提高 reserve（12~15）
- 若晋升率低但单次晋升量大（如批量读 DB 后集中处理），可保持 IHOP=45，重点提升 reserve，并监控 Humongous 区使用
真正难的不是调参，是理解 reserve 不是“保险丝”，而是“调度缓冲区”——它不解决根本的内存压力，只买时间换空间。一旦发现调高 reserve 后 Old GC 仍频繁，就得回头查对象生命周期、缓存泄漏或大对象分配逻辑。
