java应用因gc参数配置不当引发崩溃，表现为cpu 100%、频繁full gc、响应超时或oom被kill；排查需按“确认gc异常→定位参数根源→验证修复效果”三步进行，结合gc日志、jvm参数、运行时指标交叉分析，并在容器环境下重点检查cgroup内存限制与参数适配。
Java 应用因 GC 参数配置不当引发的系统崩溃，往往表现为 CPU 持续 100%、Full GC 频繁、响应超时甚至进程直接 OOM 被 kill。排查核心在于“确认是否 GC 异常 → 定位参数问题根源 → 验证修复效果”，而非盲目调参。
看 GC 日志：确认是不是收集器在“拖垮”系统
启动时未加 -Xlog:gc*（JDK 10+）或 -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:gc.log（JDK 8/9），等于闭眼开车。必须先拿到真实 GC 行为：
- 检查日志中 Full GC 间隔是否急剧缩短（如从几小时缩至几十秒），说明堆内存持续无法回收，可能 Survivor 区太小或老年代过早晋升
- 观察单次 GC 停顿时间是否超过 2 秒且频繁发生，大概率是 CMS 失败导致 Concurrent Mode Failure，或 G1 的 Mixed GC 无法及时完成
- 注意日志末尾是否有 "to-space exhausted"（G1）、"promotion failed"（CMS/Parallel）等关键错误提示，直接指向参数失配
查 JVM 启动参数：重点盯这三类高危配置
很多崩溃源于“复制粘贴式调参”，忽略业务特征与 JDK 版本适配：
- 年轻代大小硬编码：如 -Xmn512m 固定值，在容器环境下易被 cgroup 内存限制截断，实际可用堆远小于预期，触发频繁 Minor GC + 晋升风暴
- 混合使用不兼容收集器参数：例如 JDK 11+ 仍加 -XX:+UseConcMarkSweepGC（已移除），JVM 启动失败或退化为 Serial GC；或 G1 场景下误配 -XX:MaxGCPauseMillis=50 过低，导致 G1 不断压缩 Region，CPU 爆满
- 元空间/直接内存未设上限：漏配 -XX:MaxMetaspaceSize 或 -XX:MaxDirectMemorySize，类加载器泄漏或 Netty ByteBuf 泛滥时，直接冲垮系统内存
结合运行时指标交叉验证
光看日志不够，要和实时状态对齐：
- 用 jstat -gc
1s 观察 Eden 使用率是否长期 >95%，Survivor From/To 区是否反复切换且容量极小——说明 -XX:SurvivorRatio 设置过大，对象快速晋升 - 通过 jmap -histo:live
查看前 10 大对象类型，若大量 char[]、byte[] 或业务 DTO 未释放，大概率是缓存未设过期或流未 close，参数再优也扛不住内存泄漏 - 容器环境必查 cat /sys/fs/cgroup/memory/memory.usage_in_bytes，对比 JVM -Xmx 是否接近 cgroup limit，避免被 OS OOM Killer 杀掉却误判为 GC 问题
修复与验证：小步快跑，拒绝“一调永逸”
改完参数不验证 = 白调：
- 每次只调整一个参数（如先调 -XX:MaxGCPauseMillis，再调 -XX:G1HeapRegionSize），并记录变更前后 GC 频率、停顿、吞吐变化
- 压测时模拟真实流量模式（含突发流量），避免仅用均匀请求掩盖晋升压力；观察 30 分钟以上，确认无隐性内存堆积
- 上线后持续采集 Prometheus + JVM Micrometer 指标，设置告警：Full GC 次数/分钟 > 1、老年代使用率 > 85% 持续 5 分钟即触发通知
