g1疏散失败源于空闲region不足，需通过调高g1maxnewsizepercent、优化大对象处理、确保mixed gc及时回收及监控evacuation failure等指标来预防。
G1复制预留空间（Evacuation Reserve）不是用户直接配置的独立参数，而是G1内部为对象疏散（evacuation）自动预留的一组空闲Region，用于在Young GC或Mixed GC过程中存放从源Region复制过来的存活对象。所谓“变量迁移时发生溢出风险”，实际是指疏散失败（Evacuation Failure）——即GC过程中目标Region不足，无法完成对象复制，进而触发退化（degeneration），严重时可能引发Full GC甚至java.lang.OutOfMemoryError: GC overhead limit exceeded或元空间/堆外相关OOM。
要预防这类风险，核心不是“调大某个预留值”，而是保障疏散过程有足够、可用、低竞争的空闲Region供给。以下是关键调优方向和实操建议：
合理设置年轻代动态范围
G1通过`-XX:G1NewSizePercent`和`-XX:G1MaxNewSizePercent`控制年轻代Region数量上下限。若上限过低（如默认40%），在高分配压力下，年轻代会快速撑满，导致： - Eden区无空间分配新对象； - Survivor区无冗余空间容纳晋升对象； - 更关键的是：**没有足够空闲Region作为疏散目标**。建议：
- 对写入密集、对象分配速率高的应用（如实时计算、缓存服务），将
-XX:G1MaxNewSizePercent=60（上限调至60%）； - 同时设
-XX:G1NewSizePercent=20，避免初始年轻代过小导致早期频繁YGC； - 配合
-XX:G1HeapRegionSize=1M（小Region可提升碎片利用率，尤其利于中等大小对象疏散）；
抑制大对象（Humongous Object）干扰疏散调度
单个超过Region一半大小的对象（如>512KB@1MB Region）会被标记为Humongous，并独占一个或多个连续Region。这类Region： - 不能参与疏散（不可被回收或移动）； - 占用大量物理空间却无法被G1灵活调度为疏散目标； - 容易造成“假性内存紧张”，间接挤压疏散预留空间。建议：
- 检查GC日志中
Humongous allocation频率（关键词：humongous或H）； - 若高频出现，优先优化代码：拆分大数组、复用缓冲区（如
ByteBuffer.allocateDirect()改用池化）、避免new byte[1MB+]； - 必要时增大
-XX:G1HeapRegionSize（如设为2M或4M），使原本的Humongous对象变为普通对象，纳入常规疏散流程；
确保混合回收（Mixed GC）及时清理老年代碎片
疏散失败常发生在Mixed GC未能及时回收老年代Region，导致空闲Region池枯竭。G1依赖并发标记进度与`-XX:G1MixedGCCountTarget`、`-XX:G1OldCSetRegionThresholdPercent`等参数决定每次Mixed GC回收多少老年代Region。建议：
- 启用
-XX:G1UseAdaptiveIHOP（JDK10+默认开启），让G1根据历史晋升速率自动调整并发标记启动时机（IHOP）； - 若观察到
Concurrent Cycle启动延迟（如日志中Concurrent Mark Cycle间隔远超预期），可适当降低-XX:G1InitiatingOccupancyPercent=35（默认45%），提早触发标记； - 设置
-XX:G1MixedGCCountTarget=8（默认8）并配合-XX:G1OldCSetRegionThresholdPercent=10，确保每次Mixed GC回收足够多的老年代Region，持续补充空闲Region池；
监控与验证关键指标
仅靠参数不够，需结合日志确认疏散是否健康：- 开启详细GC日志：
-Xlog:gc*,gc+heap=debug,gc+ergo*=trace:file=gc.log:time,tags,uptime - 关注以下信号：
-
Evacuation Failure字样 → 直接告警，必须处理； -
to-space exhausted→ 疏散目标空间耗尽； -
Mixed GC后Free Regions数长期低于200 → 预留空间持续吃紧； -
Humongous regions计数持续增长 → 大对象堆积风险。
-
不复杂但容易忽略。
