-xx:g1newsizepercent仅设定年轻代初始下限（默认5%），g1会基于负载、停顿目标和分配速率在该值与g1maxnewsizepercent间动态调整年轻代region数，不固定大小、不控吞吐或暂停时间。
-XX:G1NewSizePercent 仅设定年轻代在堆中的初始下限（默认5%），它不固定年轻代大小，也不直接控制扫描吞吐或暂停时间。G1 会基于实际运行负载、停顿目标和内存分配速率，在 -XX:G1NewSizePercent 和 -XX:G1MaxNewSizePercent（默认60%）之间动态调整年轻代所占 Region 数量。
理解它的作用边界
该参数不是“设置年轻代大小”，而是告诉 G1：“别把年轻代缩到比这个比例还小”。例如设为8%，意味着 G1 在启动初期至少划出堆的8%作为年轻代 Region；但若业务分配快、YGC 频繁，G1 会自动扩大，只要不超过 -XX:G1MaxNewSizePercent 上限。
- 设得太低（如2%）：早期 YGC 过于频繁，总 STW 时间上升，可能拖慢吞吐
- 设得过高（如30%）：初期 YGC 回收区域少、单次暂停短，但很快被 G1 自适应机制覆盖，后续反而可能挤占老年代并发标记资源
- 它不影响 Eden/Survivor 比例，默认仍是 8:1:1，该比例随年轻代 Region 总数同步伸缩
配合 -XX:MaxGCPauseMillis 做有效微调
G1 调整年轻代规模的核心驱动力是停顿时间目标。当观察到 YGC 平均耗时持续超过 -XX:MaxGCPauseMillis 设定值时，可谨慎微调：
- 小幅提高 -XX:G1NewSizePercent（如从5%→7%），为短期突发分配提供缓冲，减少 YGC 次数
- 同步确认 -XX:G1MaxNewSizePercent 是否足够（如业务晋升率高，可设为70%），避免年轻代“涨不动”而被迫提前触发 Mixed GC
- 不要同时大幅压低 -XX:MaxGCPauseMillis 并拉高 -XX:G1NewSizePercent，二者逻辑冲突，易导致 G1 反复震荡、策略失效
先定位瓶颈，再决定是否调整
所谓“年轻代占比不合适”，往往只是表象。真实问题常在别处：
- YGC 后 Eden 几乎清空，但 STW 时间长 → 重点查 RSet 扫描开销（跨 Region 引用过多），不是调 G1NewSizePercent
- Mixed GC 效率低、老年代 Region 回收慢 → 问题在并发标记进度或 Evacuation 带宽，此时扩大年轻代反而抢占资源
- 频繁 Humongous 分配 → 应优化对象大小或调 -XX:G1HeapRegionSize，与年轻代占比无关
验证比调整更重要
每次修改后必须用工具观测实际效果：
- 用 jstat -gc
看 Young Gen Size(MB) 的波动范围，确认是否真在预期区间内变化 - 统计 YGC 次数/分钟 + 平均耗时，理想状态是频率适中、单次稳定贴近 MaxGCPauseMillis
- 关注 Mixed GC 触发频次：若因年轻代调得过大，导致老年代更快达到 InitiatingHeapOccupancyPercent 阈值，反而引发过早混合回收
