Java应用GC吞吐量需用日志首尾时间戳差值减去所有real=xxx secs累加值再除以总时间计算，停顿时间必须取real字段而非user/sys，推荐GCViewer或GCeasy工具分析，并按业务设定阈值（如Web服务吞吐量≥99%、P99停顿≤60ms）。
Java 应用的 GC 吞吐量和停顿时间不是日志里直接标出的数字，得靠日志中的原始数据手动计算或借助工具解析。关键在抓准两个核心值：所有 GC 的真实停顿总和（即所有 real=xxx secs 累加），以及应用实际运行的总时长（首尾时间戳差）。
从 GC 日志里提取吞吐量所需数据
吞吐量 = (总运行时间 − GC 总停顿时间) ÷ 总运行时间 × 100%
- 总运行时间 = 日志第一行时间戳到最后一行时间戳的差值（单位秒）。例如首行为
2026-10-09T08:12:05.111，末行为2026-10-09T12:47:22.889，差值约 4 小时 35 分钟 ≈ 16517 秒 - GC 总停顿时间 = 所有 GC 记录末尾
[Times: ..., real=0.047 secs]中的 real 值累加。注意不是 user 或 sys，也不是 jstat 里的 YGCT/FGCT（那是 CPU 时间总和，含并行叠加） - 必须开启详细日志参数才能拿到这些数据：
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/path/gc.log
识别和统计真实停顿时间（STW）
每条 GC 日志结尾的 real=xxx secs 就是单次 STW 的真实挂起时长，它反映用户线程被阻塞的实际毫秒数。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- G1 日志中常见如：
[GC pause (G1 Evacuation Pause) (young), 0.1234567 secs]，末尾数字即 real 值 - CMS 或 Parallel GC 日志也类似，格式为
[Times: user=0.102, sys=0.008, real=0.110 secs] - 别漏掉 Full GC、Mixed GC、Humongous Allocation 触发的停顿，它们都计入总停顿
- 高频小停顿（如每秒一次 YGC，每次 30ms）比低频大停顿（如每小时一次 FGCC，每次 500ms）对吞吐量影响更大
用工具快速获得准确结果
人工逐行加总易出错且耗时，推荐用成熟分析工具代替肉眼排查。
立即学习“Java免费学习笔记（深入）”；
- GCViewer：开源免费，拖入 gc.log 即可显示 Total Pause Time 和 Pause Time %，还附带停顿分布直方图和内存趋势图
- GCeasy：在线上传日志，自动聚合所有 STW 阶段，给出吞吐量百分比、P95/P99 停顿、GC 频率等关键指标
- JDK 9+ 推荐用新式日志开关：
-Xlog:gc*:file=gc.log:time,uptime,level,tags，兼容性更好，不会遗漏元空间回收或 ZGC 阶段
结合业务设定健康阈值
算出数值后要对照业务场景判断是否异常。
- 吞吐量低于 95% 就需干预；Web API 类服务建议 ≥99%，批处理类可放宽至 ≥92%
- 停顿时间不能只看平均值，重点盯 P95 和 P99。若服务 SLA 要求 TP9999 ≤ 80ms，那 GC 最大停顿最好压到 60ms 内
- GC 频率也是线索：YGC 间隔短于 30 秒、FGC 每小时发生多次，往往意味着堆配置不合理或存在内存泄漏
