parallel gc日志通过回收类型标识、堆空间变化、耗时与线程时间三类信息还原回收阶段逻辑：标识区分young gc或full gc；psyounggen/paroldgen变化反映代间对象流动；real耗时和gc cause揭示阶段异常根因。
Parallel GC 的日志结构清晰、字段稳定，适合快速定位回收阶段行为。关键不是找“开始”“结束”字样，而是通过日志中三类核心信息——回收类型标识、堆空间变化、耗时与线程时间——还原出完整的回收阶段逻辑。
看回收类型标识，确认是 Young GC 还是 Full GC
Parallel GC 日志开头就明确告诉你当前执行的是哪一阶段：
- [GC (Allocation Failure)]：典型的年轻代回收（Minor GC），说明 Eden 区已满，触发新生代收集；
- [Full GC (Ergonomics)] 或 [Full GC (Metadata GC Threshold)]：跨代回收，包含年轻代 + 老年代（ParOldGen）+ 元空间，属于整堆回收阶段；
- 若出现 [GC (System.gc())]，则是显式调用触发，不属于自动回收阶段，但会强制进入 Full GC 流程。
拆解堆空间变化，区分新生代与老年代行为
Parallel GC 日志采用“分段式结构”，每行都隐含阶段线索：
-
PSYoungGen 部分：如
[PSYoungGen: 70640K->10116K(141312K)]，表示年轻代 GC 前后存活对象大小及总容量，若回收后仍剩大量对象（比如 10116K 接近容量上限），说明对象存活率高，可能正经历晋升压力； -
ParOldGen 或 Tenured 部分：如
[ParOldGen: 12000K->12500K(62464K)]出现在某次 Minor GC 日志中，代表有对象提前晋升到老年代，这是年轻代回收阶段向老年代扩散的关键信号； -
整体堆变化：如
80541K->20017K(227328K)，反映全堆回收效果；若 Minor GC 后整体堆下降不多（比如只降了几 MB），但 ParOldGen 明显上涨，说明大量对象“逃逸”出年轻代，回收阶段实际已牵连老年代预备动作。
结合耗时与 GC Cause，判断是否发生阶段异常
Parallel GC 是吞吐量优先的并行回收器，其阶段耗时和原因直接反映系统负载状态：
- real=0.0172573 secs 是 STW 实际暂停时间，若频繁超过 10ms（尤其在低延迟服务中），需检查是否因 Survivor 空间不足导致对象批量晋升，从而加重老年代压力；
- GC Cause 是阶段根因：Allocation Failure 是正常分配节奏；Ergonomics 表示 JVM 自适应策略触发 Full GC（如老年代使用率达阈值）；Metadata GC Threshold 则暴露元空间即将耗尽，属于类加载阶段的资源瓶颈；
- 若连续多次 Minor GC 后，ParOldGen 使用量阶梯式上升（如每次 +5MB~8MB），说明年轻代回收阶段已无法有效拦截长生命周期对象，系统正滑向 Full GC 阶段临界点。
