G1通过Region划分、回收价值评估和-XX:MaxGCPauseMillis目标导向策略主动控制STW，而非强制截断；其核心是动态选择高性价比Region回收，在多数情况下将单次停顿控制在设定范围内。
G1 垃圾回收器的 STW 时间不是靠“强制截断”实现的，而是通过区域化、价值驱动和目标导向的策略主动控制。它不保证每次停顿都严格等于设定值，但会动态权衡回收收益与时间开销，在绝大多数情况下把单次 STW 控制在预期范围内。
核心机制：Region + 回收价值评估
G1 把堆划分为多个固定大小的 Region（默认最多 2048 个），每个 Region 可动态归属新生代或老年代。关键在于，G1 持续追踪每个 Region 的“回收价值”——即预估回收该 Region 所需时间、可释放空间、跨区引用（Remembered Set）复杂度等。GC 触发时，它只挑选一批“性价比高”的 Region 进行回收，确保在 -XX:MaxGCPauseMillis 设定的目标窗口内完成工作，而不是扫完整个代。
真正起效的关键参数
以下参数直接影响 STW 时长的可控性，缺一不可：
- -XX:+UseG1GC：必须显式开启，不能依赖默认（某些 JDK 版本默认非 G1）
- -XX:MaxGCPauseMillis=200（推荐起点）：设为软目标，不是硬上限；设太低（如 50）会导致频繁 Young GC，反而抬高整体 STW 次数和 CPU 开销；设太高（如 500）则失去 G1 的低延迟意义
- -Xms 和 -Xmx 相等：避免堆动态伸缩干扰 Region 大小推算，防止并发标记失败（Concurrent Mode Failure）引发 Full GC
- -XX:G1HeapRegionSize=1M 或 2M：若应用常分配 >512KB 对象（如大缓存、IO buffer），手动设大可减少跨 Region 引用，降低 Remembered Set 扫描开销
容易被忽略的隐性影响因素
很多 STW 超时问题其实来自代码层，和 JVM 参数无关：
- 大量短期存活的中等对象（几百 KB）直接晋升到老年代，导致 Mixed GC 频繁且沉重——检查 Survivor 区是否过小、-XX:MaxTenuringThreshold 是否过高
- 循环中反复
new StringBuilder().append(...).toString()，生成大量临时大字符串，易触发 Humongous Allocation，直接进老年代并占用连续 Region - Logback 等框架在每次请求中 new MDC Map，或 ThreadLocal 存放大缓存，都会显著推高年轻代分配速率，间接加剧 Young GC 频率与停顿
- 启用 -XX:+UseStringDeduplication 会在线程加锁扫描字符串，延长 Evacuation 阶段 STW，除非确认有海量重复字符串，否则建议禁用
验证是否真受控：看阶段日志，不只看平均值
别只盯着 GC 日志里 “real=xxx secs”，要定位毛刺来源：
- 用 -Xlog:gc*,gc+phases:file=gc.log:time,tags（JDK 10+）打开详细阶段日志，重点关注 Evacuation 中的 Root Region Scan 和 Remembered Set Processing 耗时占比
- 若这两项占 Evacuation 总时长 60% 以上，说明跨代引用太密，需优化对象图结构（如减少长生命周期对象持有短生命周期对象的引用）
- 用 jstat -gc -h10 <pid> 1000 持续采样，观察 G1YGC/G1MixedGC 的频次与耗时波动，识别周期性尖峰
