parallel gc停顿时间直接看日志末尾real=xxx secs或括号内secs值，即真实stw耗时；需结合gc类型、cause字段及内存变化分析，优先排查young gc持续>80ms或full gc频繁等根因。
Parallel收集器的GC停顿时间，直接看日志末尾的 real=xxx secs 或括号内明确标出的秒数，就是真实STW耗时——不是估算值，也不依赖监控工具。
识别日志中的真实停顿字段
Parallel GC日志中，停顿时间通常以两种形式出现：
- 带时间戳格式：例如
[2026-06-13T23:15:42.887+0800] GC pause (young), 0.0321456 secs→ 0.0321456 secs 就是本次Young GC真实停顿 - 详细统计格式：例如
[Times: user=0.123 sys=0.004, real=0.035 secs]→ 只有 real 值代表应用线程被挂起的实际时长，user/sys是GC线程占用的CPU时间，不能反映停顿
区分不同GC类型的停顿特征
Parallel下常见GC类型对应停顿表现差异明显：
- Young GC：一般在10–50ms之间，若持续 >80ms，需检查年轻代是否过小、对象分配速率是否过高（如Eden区频繁满且间隔短）
-
Full GC（Parallel Old）：日志中明确含
Full GC字样，停顿常达数百毫秒至数秒，典型信号是[Full GC (Ergonomics)]或[Full GC (System.gc())]，必须优先排查 -
老年代触发的GC：如日志中出现
Allocation Failure却发生在老年代回收阶段，说明晋升失败或担保失败（Concurrent Mode Failure不属Parallel，但类似诱因如老年代碎片/空间不足也会导致Full GC）
结合关键指标定位高停顿根因
单看停顿数字没意义，要联动日志中其他字段交叉判断：
-
看内存变化：例如
[PSYoungGen: 12288K->1024K(13312K)] [ParOldGen: 26214K->25600K(26624K)]→ 若老年代回收后仅减少614K，但停顿却达1.2s，说明压缩过程慢，可能因老年代碎片严重或对象引用链太深 -
看GC Cause：日志中
Cause: Allocation Failure是正常触发；若为Cause: Ergonomics却伴随长时间Full GC，大概率是堆初始配置不合理（如-Xms与-Xmx差值过大，触发多次扩容+Full GC） -
看频率与累计耗时：用
jstat -gc <pid> 1000</pid>观察FGCT（Full GC总耗时）和YGCT（Young GC总耗时），若FGCT占GCT比例超10%，说明Full GC已成性能瓶颈
调优时避开常见参数误区
Parallel GC下盲目调参反而加剧停顿：
- 不要只设 -XX:MaxGCPauseMillis：它只是目标，JVM会通过缩小年轻代来“达标”，结果导致Young GC频率飙升、总停顿反升
- 慎用 -Xmn 固定年轻代大小：禁用自适应策略后，GC无法根据负载动态调整，容易在流量高峰时因Eden过载引发更频繁GC
- 合理设置 -XX:ParallelGCThreads：默认值通常合适（≈CPU核心数），设得过高会引发线程竞争，反而延长STW；8核机器设6–8个足够，不必强拉到16
