g1混合回收由并发标记完成后的下一次ygc触发，而非直接由-xx:initiatingheapoccupancypercent（ihop）触发；该参数仅控制并发标记周期启动时机，默认45%，作用于整个堆，触发后经初始标记、并发标记、最终标记、清理等阶段，待完成后下一次ygc自动升级为mixed gc。
G1 的混合回收（Mixed GC）不会直接由 -XX:InitiatingHeapOccupancyPercent（简称 IHOP）触发，这个参数真正控制的是并发标记周期（Concurrent Marking Cycle）的启动时机——而混合回收是在并发标记完成之后、下一次垃圾回收中自动发生的。理解这一点，是避免调优误操作的关键。
什么是 -XX:InitiatingHeapOccupancyPercent？
它定义了整个 Java 堆内存占用率达到多少百分比时，G1 启动并发标记。默认值为 45%，即当老年代 + 新生代已用空间总和 ≥ 堆总容量 × 45% 时，G1 开始并发标记阶段。
- ✅ 作用对象：整个堆（不是仅老年代）
- ✅ 触发动作：启动并发标记（Concurrent Marking），为后续 Mixed GC 做准备
- ❌ 不直接触发：Young GC、Mixed GC 或 Full GC
注意：JDK 9+ 中该参数仅作为初始值，G1 会基于历史标记数据动态调整 IHOP 值（称为“自适应 IHOP”），以更精准预测下次并发标记应何时开始。
混合回收是怎么被触发的？
混合回收的发生依赖两个前提：
- 并发标记已完成（包括初始标记、并发标记、最终标记、清理等阶段）
- 下一次 YGC 或分配失败后，G1 判定需回收部分老年代 Region（即满足“混合”条件）
所以真正的触发链是：
堆占用达 IHOP阈值 → 启动并发标记 → 标记完成 → 下次 YGC 升级为 Mixed GC（回收 Eden + 部分老年代 Region）
如果并发标记还没完成，即使堆继续增长，也不会提前执行 Mixed GC；反之，若标记早已完成但一直没发生 YGC（比如应用分配压力极低），Mixed GC 也不会“空转”。
如何合理调优 IHOP？
调优目标是：让并发标记在老年代真正“快撑满”前完成，避免因标记滞后导致 Mixed GC 来不及介入，最终退化为 Full GC。
常见调优场景与建议：
频繁发生 Full GC
可能原因：IHOP 设置过高（如 60），导致并发标记启动太晚，老年代已接近耗尽才开始标记 → 标记未完就触发分配失败 → FGC
✅ 建议：适当降低 IHOP（如设为 35~40），让标记提前启动，留出安全缓冲并发标记太频繁、CPU 开销大
可能原因：IHOP 设置过低（如 25），堆刚用到 1/4 就启动标记，但实际老年代还很空，标记收益低
✅ 建议：结合 GC 日志观察Concurrent Cycle Initiated和Mixed GC的间隔，适度提高至 40~45（默认值通常合理）大堆（≥16GB）、长周期服务（如 Kafka、Flink）
✅ 推荐开启-XX:+G1UseAdaptiveIHOP（JDK8u191+ / JDK9+ 默认开启），让 G1 自动学习并优化 IHOP
✅ 同时监控日志中的IHOP (target): xxx MB和predicted old gen occupancy，验证是否收敛稳定
补充：如何确认 IHOP 是否生效？
开启详细 GC 日志（推荐使用 -Xlog:gc*,gc+ergo*=trace）后，可搜索以下关键信息：
-
Concurrent Cycle Initiated→ 表明因 IHOP 达标而启动标记 -
Ergonomics: initiated concurrent cycle because of heap occupancy→ 明确归因于堆占用 -
IHOP (target)和predicted old gen occupancy→ 查看当前 G1 预估的老年代占用与 IHOP 目标对比
若长期只看到 initiated because of System.gc() 或 allocation failure，说明 IHOP 未起作用，可能是堆实际占用始终未达阈值，或被其他条件覆盖（如显式 GC 干扰）。
不复杂但容易忽略
