g1停顿预测模型面向几十至两百毫秒的可预测停顿，不追求亚毫秒级延迟；它通过衰减平均值估算目标时间内可回收region数，优先选择高价值region组成cset，并主动削减规模以保障停顿上限，但单次stw下限受必要步骤约束，典型生产停顿为10–200ms。
G1 的停顿预测模型本身不追求亚毫秒级延迟，它面向的是几十到两百毫秒量级的可预测停顿。所谓“亚毫秒级”（
如果你在日志或监控中观察到个别 G1 GC 停顿接近 1ms，那通常是 Young GC 在极轻负载、小堆、低对象分配率下的偶然结果，而非模型主动保障的能力。G1 的 Pause Prediction Model 是为可控、可预期的毫秒级停顿服务的，不是为亚毫秒优化的。
下面从模型机制出发，说明它实际能做什么、不能做什么，以及为什么容易误解：
停顿预测模型的核心逻辑是“做减法”，不是“压极限”
G1 不靠压缩单次操作耗时来降延迟，而是通过三步动态控制回收工作量：
- 根据 -XX:MaxGCPauseMillis 设定的目标（如 200ms），结合历史 Region 回收耗时的衰减平均值，估算“这 200ms 内最多能处理多少个 Region”
- 优先挑选垃圾密度高、复制成本低的 Region（即回收价值最高者）组成 CSet（回收集）
- 若预测总耗时会超目标，就主动削减 CSet 规模，宁可少回收几个 Region，也不突破停顿上限
这种策略天然存在下限：哪怕只回收 1 个 Region，也要完成根扫描、对象复制、引用更新、卡表处理等必要步骤。在典型生产环境（4GB+ 堆、多线程分配），Young GC 实际停顿通常在 10–50ms，Mixed GC 则视老年代污染程度在 50–200ms 波动。
Agent Browser
下载
一款AI工具，主要用于一款基于 Rust 的快速无头浏览器自动化命令行工具（CLI），支持 Node.js 回退机制，可使 AI agent 通过结构化命令实现页面导航、点击、输入及截图，适合需要提升相关任务效率的用户。
为什么有人误以为 G1 能到亚毫秒？常见混淆点
- 把“并发阶段耗时”当成 STW 停顿：G1 的初始标记、并发标记、最终标记中的部分阶段是与应用线程并发执行的，这些时间不计入 GC 日志里的 pause time，但容易被监控工具错误归类
- 忽略硬件与负载前提：在 1GB 堆、单线程、无对象晋升的测试场景下，G1 Young GC 可能压到 2–3ms，但这不具备生产参考价值
- 混淆 ZGC 特性：ZGC 使用着色指针 + 读屏障 + 并发转移，将 STW 严格限制在根扫描和重映射阶段，天然支持
如果你真需要亚毫秒级，该怎么做？
- 明确 GC 目标：若业务 SLA 要求 P99 GC 停顿
- 切换收集器：JDK 11+ 推荐 ZGC，JDK 15+ 可选 Shenandoah；两者均通过并发转移避免大部分对象移动 STW
- 配合代码优化：减少临时对象分配、避免巨型对象、使用对象池（谨慎）、控制晋升年龄，这些对 G1 有效，但对 ZGC 更关键——因为 ZGC 的并发能力依赖于应用配合
G1 的价值在于“在大堆、多核、混合负载下，把不可控的老年代 Stop-The-World 变成可配置、可预期的多次小停顿”。它解决的是 CMS 时代“偶发秒级 Full GC”的可靠性问题，而不是挑战物理延迟极限。
