JVM 垃圾回收常见报错怎么排查解决-java教程-PHP中文网

jvm垃圾回收报错核心是对象生命周期失控而非内存不足：oom-heap表明老年代长期超95%且full gc释放极少；gc overhead limit exceeded说明gc耗时占比过高但回收率低；metaspace oom则指向动态类加载泄漏，需针对性排查代码而非盲目调参。

jvm 垃圾回收常见报错怎么排查解决

遇到 JVM 垃圾回收相关报错，别急着调参数或加内存。核心思路是：先确认是不是 GC 真的“干不动了”，再定位哪类对象在拖后腿，最后从代码生命周期入手解决——不是堆不够，而是对象不肯走。

常见报错不是孤立的，每种都指向特定内存行为异常：

java.lang.OutOfMemoryError: Java heap space：堆空间真被占满，GC 回收后仍无足够连续空间分配新对象。典型表现是老年代使用率（OU/OC）长期 >95%，且 Full GC 后释放极少。
java.lang.OutOfMemoryError: GC overhead limit exceeded：不是内存耗尽，而是 GC “累瘫了”——默认情况下，98% 的时间花在 GC 上，却只回收 ≤2% 的堆内存。说明大量对象反复进入老年代又无法释放，比如缓存未清理、监听器未注销、ThreadLocal 未 remove。
java.lang.OutOfMemoryError: Metaspace：元空间爆了，多见于动态生成类（如 Spring Boot + CGLIB、热部署、大量反射代理），不是堆问题，调 -Xmx 没用，得看 -XX:MaxMetaspaceSize 和类加载行为。
频繁 Full GC 但回收量小：jstat -gc 显示 FGCT（Full GC 总耗时）持续上升，而 FGC（次数）和 FGCT/FGC 比值高，说明每次 Full GC 都在“白忙活”，大概率是老年代对象堆积+无法回收。

生产环境出问题，优先抓可观测性数据，不靠猜：

Gradle 9.8.0

下载

实时观察 GC 行为：运行 jstat -gc 2000，重点关注 OU（老年代已用）、OC（老年代容量）、YGC/YGCT（年轻代 GC 次数/耗时）。若 OU 单向爬升、YGC 频繁但对象不断晋升，说明新生代存活率高或 Survivor 区太小。
紧急 dump 堆快照：执行 jmap -dump:format=b,file=heap.hprof ，用 VisualVM 或 Eclipse MAT 打开，按 Dominator Tree 排序，重点看 HashMap、ArrayList、ConcurrentHashMap、自定义缓存类的实例数和 retained heap。特别留意匿名内部类（如 Runnable、Listener）隐式持有大对象引用的情况。
查 GC 日志找模式：启用 -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:gc.log。如果日志里反复出现 Full GC，且每次只回收几 MB，基本可断定是对象生命周期失控，而非内存配置不合理。

改代码比调 JVM 参数更治本，尤其避免“掩耳盗铃”式操作：

别一上来就 -Xmx 调大：堆扩大可能延缓 OOM，但掩盖了对象泄漏本质；反而让 GC 更慢、停顿更长。应先确保 -Xms 和 -Xmx 相等，避免堆动态扩容带来的额外开销。
WeakReference / SoftReference 不是银弹：WeakReference 可能在下一次 Minor GC 就被清掉，不适合“可能还要用”的缓存；SoftReference 在 JDK 8+ 默认按内存压力延迟回收，压力不大时比强引用还顽固。真正稳妥的是显式清理：cache.remove(key)、listenerMap.remove(this)、threadLocal.remove()。
检查三类高危代码模式：静态集合（static List/Map）持续 add 不清理；线程池中 Runnable 持有外部大对象且任务长期积压；ThreadLocal 存储大对象但未在 finally 中 remove。这些是 GC overhead 和 Full GC 的主力推手。
元空间问题单独处理：出现 Metaspace OOM，先加 -XX:MaxMetaspaceSize=512m 临时兜底，再用 jstat -class 查 loaded class 数量是否持续增长，结合 Arthas trace 类加载路径，定位动态代理或热部署泄漏点。