jvm性能监测中，gc指标是应用健康状态的“心电图”，需关注停顿时间、吞吐量、堆内存分布、晋升行为及gc原因。停顿时间影响用户感知，吞吐量反映cpu资源分配，老年代使用率超75%属高危，survivor区饱和预示晋升异常，gc cause揭示根本诱因。
JVM性能监测中，GC指标不是一堆数字，而是应用健康状态的“心电图”。看懂它们，才能在系统变慢、响应延迟、OOM前主动干预。核心不在于记全所有字段，而在于理解每个指标背后反映的内存行为逻辑。
停顿时间（GC Latency）
指单次GC导致应用线程暂停的时长（STW），直接影响用户感知。比如一次Full GC停顿2秒，所有HTTP请求都会卡住2秒。
- 重点关注FGCT（Full GC总耗时）和YGCT（Young GC总耗时）的单次均值与峰值，而非仅看总量
- TP9999为50ms的应用，建议将MaxGCPauseMillis设为40ms，并配合G1或ZGC使用
- 若YGC平均停顿超10ms，说明Eden区过小或对象分配速率突增；若FGC单次超500ms，大概率存在大对象堆积或内存泄漏
吞吐量与GC频率
吞吐量 = 应用执行时间 /（应用执行时间 + GC时间），本质是CPU资源在业务与GC之间的分配比例。
- 生产环境建议吞吐量长期稳定在99.5%以上；低于99%需警惕——意味着每分钟有3秒以上在做GC
- YGC频次高（如>10次/秒）但每次耗时短，多因Eden太小，可调大-Xmn或用-XX:NewRatio=2扩大新生代
- FGC频次上升（如从每天0次变为每小时1次）是严重信号，需立即排查老年代持续增长或晋升异常
堆内存分布与晋升行为
看GC日志或jstat输出时，不能只盯“用了多少”，更要关注“怎么用的”。
- 老年代使用率（OU/OCC）连续30分钟>75%，即使没触发FGC也属高危——说明活跃对象过多或CMS/G1并发失败
- Survivor区使用率（S0U/S1U）长期接近100%，且YGC后S0U骤降、S1U飙升，说明Survivor空间不足，对象被迫直接晋升
- 晋升速率（Promotion Rate）接近对象分配速率（Allocation Rate），意味着大量对象“活不过一轮YGC”，可能因-XX:MaxTenuringThreshold设得太低，或业务创建了大量中生命周期对象
GC原因与回收类型
GC Cause字段（如“Allocation Failure”“Metadata GC Threshold”“System.gc()”）比次数更重要——它告诉你GC为何发生。
- “Allocation Failure”为主因，说明Eden满，属正常；若占比低于80%，需查是否有显式System.gc()调用或元空间不足触发的GC
- “Metadata GC Threshold”频繁出现，提示Metaspace快满，应加大-XX:MaxMetaspaceSize
- “System.gc()”出现在日志中，说明代码里调用了Runtime.getRuntime().gc()，属于反模式，需清理
