gc耗时占比是评估jvm健康度的核心指标，计算公式为吞吐量=(总运行时间−gct)/总运行时间×100%，生产环境建议吞吐量≥99%（gct≤1%），需合并ygct与fgct统计，避免低估full gc影响，并借助gceasy等工具验证gc开销占比是否超10%预警线。
GC 耗时占比是评估 JVM 系统健康度最直接、最落地的指标之一——它不看单次停顿多吓人，而是算“应用真正干活的时间占了多久”。占比越低，说明 CPU 和线程资源越集中在业务逻辑上，系统越稳健。
看 GCT 占比：吞吐量 = (总运行时间 − GC 时间) / 总运行时间 × 100%
从 jstat -gc
- 例如：JVM 运行 3600 秒（1 小时），GCT = 28.5 秒 → 吞吐量 ≈ (3600−28.5)/3600 × 100% ≈ 99.21%
- 生产环境建议底线：吞吐量 ≥ 99%（即 GC 耗时占比 ≤ 1%，每小时最多允许约 36 秒 GC 时间）
- 不同场景容忍度不同：Web API 类服务应更严格（建议 ≤ 3% 即 GCT ≤ 108 秒/小时），批处理任务可放宽至 ≤ 8%
别只加 YGCT：必须把 YGCT + FGCT 合并计算
很多人只盯着 Young GC 耗时，忽略 Full GC 的“隐形杀伤力”。一次 Full GC 停顿 2.3 秒，可能抵得上 100 次 Young GC。GCT 是两者之和，漏掉 FGCT 会严重低估真实损耗：
- jstat 输出中：YGCT（Young GC 总耗时）、FGCT（Full GC 总耗时）、GCT = YGCT + FGCT
- 若 FGCT 占 GCT 的 40% 以上，即使频次不高，也说明老年代存在隐患（如对象过早晋升、缓存未释放、元空间压力）
- 日志中出现 System.gc() 或 Metadata GC Threshold 触发的 Full GC，需单独标记并排除在自然负载评估之外
高频小停顿比低频大停顿更伤吞吐量
平均每次 Young GC 只有 25ms，但每秒发生 3 次 → 每分钟 GC 时间达 4.5 秒。这种“细碎卡顿”用户未必感知明显，却持续蚕食 CPU 资源：
- 用 jstat -gc
1000 60 观察 GCT 每秒增长速率：若稳定 > 0.05 秒/秒（即每分钟超 3 秒），就已超出 Web 服务健康水位 - 配合 GC 日志 grep 统计：
grep "Pause" gc.log | awk '{sum += $NF} END {print sum}'得到所有 STW 时间总和，与 jstat 的 GCT 应基本一致；若有明显偏差，说明日志参数不全（如缺 -XX:+PrintGCDetails）或用了并发收集器但未捕获全部 STW 阶段
工具验证比肉眼扫日志更可靠
人工统计百条日志极易遗漏波动点。推荐标准化路径：
- 启用结构化日志：JDK 8 用 -XX:+PrintGCDetails -Xloggc:gc.log；JDK 11+ 强制用 -Xlog:gc*:file=gc.log:time,uptime,level,tags
- 上传至 GCeasy 或本地运行 GCViewer，自动聚合「Total Pause Time」和「Pause Time %」，并标出异常毛刺、Mixed GC 比例突增等信号
- 重点关注报告中的 GC Overhead（GC 开销占比）：超过 10% 即红色预警，通常伴随响应延迟飙升或 OOM 风险
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
