CPU飙升主因是频繁Full GC，需按四步排查：先用top+jstack确认GC线程主导；再用jstat看FGC次数与老年代使用率；接着用jmap分析堆配置或dump堆快照结合MAT查泄漏；最后排除System.gc()调用或元空间耗尽等隐蔽原因。
当高并发场景下出现 CPU 飙升，且怀疑由频繁 Full GC 引起时，排查核心不是“CPU 为什么高”，而是“GC 为什么这么忙”。关键在于快速确认 GC 是否是主因，并定位其触发根源。以下是直击要害的四步排查路径：
第一步：确认 CPU 高是否真由 GC 线程主导
执行 top -Hp <java_pid> 查看线程级 CPU 占用，找出几个高耗 CPU 的线程 ID（如 12345）。再用 printf "%x\n 12345" 转成十六进制（如 3039），然后执行 jstack <pid> | grep -A 10 "nid=0x3039"。如果看到线程名是 "VM Thread" 或 "G1 Concurrent GC Thread" 等，基本可断定 CPU 高源于 GC 活动，而非业务代码死循环或正则回溯。
第二步：验证 Full GC 是否真的高频且恶化中
运行 jstat -gcutil <pid> 1000 5，重点关注三列：
- FGC：Full GC 次数 —— 若 5 秒内增长 ≥1，说明每分钟至少 12 次，属紧急级别；
- OGC / OU：老年代使用率 —— 若持续高于 90% 且 GC 后下降极少（如 95% → 94%），说明对象无法回收，极可能内存泄漏；
- MU：元空间使用率 —— 若接近 100%，需警惕动态类加载（如 Spring AOP、MyBatis Mapper、热更新框架）导致的 Metaspace 耗尽。
第三步：区分是堆内泄漏还是配置失衡
先执行 jmap -heap <pid>，观察老年代当前容量与已用空间比值。若堆总大小合理（如 4G），但老年代仅分配了 1.5G 且已占满，大概率是 -XX:MaxNewSize 或 -XX:NewRatio 设置不当，导致年轻代过小、对象过早晋升；
若老年代容量充足（如 3G）却长期 >95%，就要导出堆快照：
- jmap -dump:format=b,live,file=heap.hprof <pid>（加 live 减少干扰）；
- 用 MAT 打开后，重点看 Dominator Tree 和 Leak Suspects 报告，识别占用 Top 3 的对象类型及其强引用链 —— 常见泄漏源包括静态集合缓存未清理、ThreadLocal 持有大对象、监听器注册后未反注册。
第四步：检查是否被显式 GC 或元空间拖累
Full GC 不一定来自内存不足。两种隐蔽诱因必须排除：
- 查 GC 日志（或用 jstat -gccause <pid>）：若日志中频繁出现 System.gc() 或 Metadata GC Threshold，前者说明代码或依赖库调用了 System.gc()，应加 -XX:+DisableExplicitGC 禁用；后者说明元空间反复触顶，需结合 jstat -gcmetacapacity <pid> 看 MC（最大元空间）和 MU（已用），必要时调大 -XX:MaxMetaspaceSize；
- 检查是否使用 CMS 收集器（已废弃）且配置了 -XX:+UseCMSInitiatingOccupancyOnly 但阈值设得过低，导致老年代刚到 60% 就强制 Full GC。
