G1垃圾回收器通过分代+分区机制实现可预测停顿，核心是合理配置-XX:MaxGCPauseMillis（如200ms）并配合-Xms/-Xmx相等、堆≥4GB等参数，辅以G1NewSizePercent、G1MixedGCCountTarget等调优，再通过GC日志监控P90/P99停顿验证效果。
G1 垃圾回收器（Garbage-First GC）专为低延迟、大堆场景设计，核心目标是通过分代+分区（Region）机制，在可控的停顿时间内完成垃圾回收。要实现“可预测的停顿时间”，关键不是单纯开启 G1，而是合理配置其时间目标与相关参数，让 JVM 主动将 GC 拆分为多个小任务，并优先回收收益高（垃圾多、存活少）的区域。
设置目标停顿时间（核心参数）
G1 会尽力满足你设定的“最大期望停顿时间”，但不保证绝对精确——它是一个软目标，用于指导并发标记节奏和混合回收（Mixed GC）的工作量分配。
- -XX:MaxGCPauseMillis=200：设定期望的最大 GC 停顿时间（毫秒），例如 200ms。这是最核心的参数，建议根据业务 SLA（如接口 P99 延迟要求）留出余量设定，不要压到极限。
- G1 会动态调整每次 Mixed GC 回收的 Region 数量、是否触发并发标记周期等，来逼近该目标。值设得太小（如 50ms）可能导致频繁 GC、吞吐下降；设得太大（如 1000ms）则失去低延迟意义。
确保 G1 被正确启用并适配堆大小
仅加 -XX:+UseG1GC 不足以获得稳定表现，还需配合合理的堆结构与初始配置：
- -XX:+UseG1GC：显式启用 G1（JDK 9+ 默认，但显式声明更清晰）。
-
-Xms 和 -Xmx 设为相同值（如
-Xms4g -Xmx4g）：避免运行时堆扩容带来的额外开销和不确定性，有利于 G1 预测回收行为。 -
堆不宜过小（建议 ≥ 4GB）：G1 的分区机制在小堆上优势不明显，且 Region 数量不足会影响调度灵活性；过大（如 >64GB）需关注 Region 大小（默认 1~4MB）是否仍合理，必要时用
-XX:G1HeapRegionSize调整。
调优辅助参数提升稳定性
以下参数用于微调 G1 行为，应对实际中可能出现的停顿波动或内存压力问题：
立即学习“Java免费学习笔记（深入）”；
- -XX:G1NewSizePercent=20 与 -XX:G1MaxNewSizePercent=40：控制年轻代在堆中的占比范围（默认 5%~60%）。适当提高下限（如 20%）可减少年轻代 GC 频率；上限不宜过高，否则挤压老年代空间，增加 Mixed GC 压力。
- -XX:G1MixedGCCountTarget=8：指定一次并发标记周期后，混合回收应尽量分多少次完成（默认 8）。值越大，单次 Mixed GC 工作越轻、停顿越短，但总回收耗时可能拉长；适合对单次停顿极度敏感的场景。
- -XX:G1HeapWastePercent=5：当已标记为可回收但尚未回收的堆空间占比超过该阈值（默认 5%），G1 会提前触发 Mixed GC。适当调低（如 3）可更积极清理，减少突发大回收风险。
监控与验证是否真正“可预测”
配置只是起点，必须通过真实负载 + 日志验证效果：
- 添加
-Xlog:gc*:file=gc.log:time,tags,level（JDK 11+）或-XX:+PrintGCDetails -XX:+PrintGCTimeStamps（旧版）记录详细 GC 日志。 - 重点关注每轮
G1 Evacuation Pause（年轻代或混合回收）的实际停顿时间（user/sys/real），用工具（如 GCViewer、gceasy.io）统计 P90/P99 停顿分布，确认是否稳定落在目标范围内。 - 若发现大量
to-space exhausted或 Full GC，说明年轻代过小或晋升过快，需检查对象生命周期或调整新生代比例。
