应先通过gc日志和jstat等工具直接观察gc行为与线程状态，确认是否因young/full gc耗时过高、频率异常或内存分配失衡导致性能下降，再结合jstack分析stw影响及jinfo验证参数实际生效情况。
直接看 GC 行为和线程状态，而不是先猜参数对错。性能下降若由 JVM 调优不当引发，往往表现为吞吐骤降、响应变慢、CPU 或内存使用异常，但代码和流量没变——这说明问题出在运行时资源调度层面。
查 GC 日志确认是否被回收拖垮
开启并分析 GC 日志是最直接的判断依据：
- 加参数启动应用：-Xloggc:gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=10M
- 重点观察：YGCT/FGCT 占比（如 Young GC 耗时占总运行时间 >10%）、Full GC 频率（每小时超过 1 次需警惕）、Evacuation Failure / To-space Exhausted（G1 下典型调优失当信号）
- 用 GCViewer 或 GCEasy 可视化分析日志，快速识别停顿尖刺、内存碎片、晋升失败等模式
用 jstat 快速定位内存分配失衡
不依赖日志，实时抓取堆各区域使用趋势：
- 执行 jstat -gc
1000 ，关注字段：EU（Eden 使用率）是否长期 >95%、OU（老年代使用率）是否缓慢爬升且不下降、YGC 次数突增但 YGCT 不高（说明新生代太小） - 若 S0U/S1U 接近 S0C/S1C 且频繁切换，可能 SurvivorRatio 设置不合理，对象过早进入老年代
- 对比 OC（老年代容量）与 OU：OU 接近 OC 但 FGC 未触发，可能是 MaxGCPauseMillis 设得太保守，G1 主动回避回收
结合线程快照看是否因 STW 或锁竞争放大延迟
GC 停顿本身会卡住所有业务线程，但调优不当还会诱发次生问题：
- 用 jstack
> th.txt 抓快照，搜索 RUNNABLE 状态但堆栈停在 Unsafe.park 或 Object.wait——不是死锁，而是线程在等 GC 结束 - 检查是否有大量线程阻塞在 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await，说明 GC 延迟导致下游超时重试，加剧线程堆积
- 配合 top -H -p
找到高 CPU 线程，转成十六进制后在 jstack 中定位——若堆栈集中在 GC 相关 native 方法（如 G1CollectorPolicy::update_young_list），基本确认是 GC 参数冲突
验证 JVM 参数本身是否生效或冲突
很多“调优”失效，是因为参数根本没起作用，或相互矛盾：
- 执行 jinfo -flags
查看实际生效的 JVM 参数，确认 -Xms/-Xmx 是否相等、是否误用了已废弃参数（如 JDK8+ 还配 -XX:PermSize） - 运行 java -XX:+PrintFlagsFinal -version | grep （如 UseG1GC、MaxGCPauseMillis），核对参数是否被支持、默认值是否被覆盖
- 注意常见冲突组合：-XX:+UseG1GC 与 -XX:+UseParallelGC 同时存在（后者会覆盖前者）、-Xmn 与 -XX:NewRatio 同时设置（后者失效）
