JVM GC参数配置错误会导致CPU飙升、Full GC频繁、响应超时或OOMKilled；排查需按“现象→日志→参数→运行态→修复”闭环验证，重点检查GC日志、JVM启动参数（如-Xmn硬编码、收集器不兼容、元空间无上限）、运行时指标（jstat/jmap/cgroup内存），并小步验证修复效果。
JVM 垃圾回收参数配置错误，往往不会立刻报错，而是表现为 CPU 持续飙高、响应变慢、Full GC 频繁、服务偶发超时，甚至被系统 OOM Killer 杀掉。排查不能靠猜，得按“现象→日志→参数→运行态→修复”这条链路闭环验证。
看 GC 日志确认是否真在“GC 拖垮系统”
没开 GC 日志就调参，等于蒙眼修车。必须先确认问题本质：
- JDK 8/9 加：-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:gc.log
- JDK 10+ 推荐：-Xlog:gc*:gc.log:time,uptime
- 重点盯：Full GC 间隔是否从几小时缩到几十秒；单次 GC 停顿是否 >2 秒且反复出现；日志末尾是否有 "to-space exhausted"（G1）、"promotion failed"（Parallel/CMS）等明确失败提示
查 JVM 启动参数揪出高危配置
很多崩溃源于复制粘贴参数，忽略 JDK 版本和容器环境：
- 年轻代硬编码陷阱：如 -Xmn512m 在容器里被 cgroup 限制截断，实际新生代远小于此值，导致 Minor GC 飙升 + 大量对象提前晋升
- 收集器参数不兼容：JDK 11+ 还加 -XX:+UseConcMarkSweepGC（已移除），JVM 可能静默退化为 Serial GC；G1 下设 -XX:MaxGCPauseMillis=50 过低，会疯狂压缩 Region，CPU 直接拉满
- 元空间/直接内存无上限：漏配 -XX:MaxMetaspaceSize 或 -XX:MaxDirectMemorySize，类加载暴增或 Netty 缓冲区泛滥时，直接冲垮宿主机内存
用运行时命令交叉验证真实状态
日志是历史，jstat/jmap 是当下。二者对不上，说明问题不在 GC 参数本身，而在应用行为：
- jstat -gc <pid> 1s：观察 Eden 使用率是否长期 >95%，Survivor From/To 是否极小且频繁翻转——大概率是 -XX:SurvivorRatio 设得太大，对象“秒进老年代”
- jmap -histo:live <pid>：查前 10 大对象类型。若大量 char[]、byte[] 或业务 DTO 持续堆积，基本可判定是缓存未过期、流未 close 或静态集合泄漏，再优的 GC 参数也救不了
- 容器中务必执行：cat /sys/fs/cgroup/memory/memory.usage_in_bytes，对比 -Xmx 值。若两者接近，说明 JVM 被 cgroup “卡脖子”，不是 GC 不行，而是 OS 不让它用够内存
修复要小步快跑，拒绝一调永逸
改完参数必须验证效果，不能只看“不报错”：
- 优先确保 -Xms = -Xmx，避免堆扩容触发 Full GC；新生代建议占堆 1/3～1/2（如堆 4G，-Xmn1.5G）
- 新项目默认选 G1：-XX:+UseG1GC -XX:MaxGCPauseMillis=200；吞吐优先场景可用 Parallel：-XX:+UseParallelGC
- 加 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heap.hprof，OOM 时自动抓现场；用 MAT 分析 Dominator Tree 和 Leak Suspects 报告，直击泄漏根因
