evacuation failure 是 g1 在 mixed gc 或 young gc 阶段因目标 region（to-space）不足导致对象疏散失败，先触发降级 gc（单线程 mark-compact），仅在降级仍失败时才升级为 full gc。
G1 收集器发生 Evacuation Failure（疏散失败）时，不会直接触发 Full GC，而是先尝试降级处理：暂停所有应用线程，启用单线程、标记-整理（Mark-Compact）式的回收方式，在当前年轻代和部分老年代区域中进行更激进的回收，以腾出足够空间完成对象疏散。
什么是 Evacuation Failure
Evacuation Failure 发生在 G1 的混合回收（Mixed GC）或年轻代回收（Young GC）阶段。当 GC 线程尝试将存活对象从源 Region 复制（即“疏散”）到目标 Region 时，发现没有足够的空闲 Region 可用（尤其是 To-space 不足），导致复制无法完成，就抛出此失败。
常见诱因包括：
- 堆内存持续增长，但并发标记周期未及时启动或未完成
- 大对象（Humongous Object）频繁分配，快速耗尽可用 Region
- 应用突增分配速率，GC 周期跟不上对象晋升速度
- Region 大小配置不合理（如 -XX:G1HeapRegionSize 过大或过小）
降级处理的具体行为
Evacuation Failure 触发后，G1 不会立即跳转到 Serial 或 Parallel 的 Full GC，而是执行一次“降级 GC”（Degenerated GC），本质是同步、单线程、基于标记-整理的回收，但仍属于 G1 框架内行为：
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 暂停所有应用线程（STW 时间显著拉长）
- 对已选定的回收集（包括部分年轻代 + 已标记的老年代 Region）执行完整标记
- 将存活对象向 Region 起始端压缩整理，释放连续空闲空间
- 重新尝试疏散——此时因空间被整理，大概率能成功完成复制
该过程日志中通常显示为 "GC pause (G1 Evacuation Pause) (degenerated)"，而非 "Full GC"。
何时会真正升级为 Full GC
降级 GC 仍可能失败，主要出现在以下情况：
- 即使整理后，仍无足够连续空间容纳最大待疏散对象（尤其大对象）
- 堆已极度碎片化，且老年代几乎无可用 Region 可回收
- 降级过程中发生 OOM（如元空间、直接内存不足，间接影响 GC 执行）
此时 JVM 才会放弃 G1 流程，退回到传统的 Serial GC（默认）或所选的备用收集器，执行真正的 Full GC —— 标记-清除-整理全堆，STW 时间极长，应极力避免。
如何避免 Evacuation Failure
关键在于让并发标记及时完成、预留足够空闲 Region、控制大对象分配：
- 调优 -XX:MaxGCPauseMillis（如设为 200），让 G1 更早启动并发标记
- 确保 -XX:InitiatingOccupancyPercent 合理（默认 45%，若老年代增长快可适当下调）
- 监控 Humongous Allocation 日志（-XX:+PrintGCDetails 中的 “Humongous allocation”），减少 > 50% Region size 的对象分配
- 必要时增大堆内存或调整 Region 大小（-XX:G1HeapRegionSize），但需权衡停顿与碎片
- 开启 -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -XX:+G1UseAdaptiveIHOP（JDK 10+ 默认启用），让初始 IHOP 阈值自动学习
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
