Java GC排查需按“现象→日志→参数→工具→代码”主线推进：先开启-Xlog分析GC类型、堆变化及异常提示；紧盯GC频率、老年代增速、STW时间三大指标；用jstat/jmap/Arthas验证；最终定位代码中未断引用链（如静态缓存、未注销监听器等）导致对象无法回收。
Java 垃圾回收（GC）的高频痛点，不是靠“查教程”就能解决的，而是要直击现象、定位根源、验证假设。真正有效的排查路径，是围绕 现象 → 日志 → 参数 → 工具 → 代码 这条主线展开。
看 GC 日志，而不是搜“教程”
GC 日志是 JVM 给你的第一手诊断报告，比任何教程都真实。 开启方式（JDK 8/11/17+ 推荐统一用 `-Xlog`）：-Xlog:gc*:stdout:time,uptime,level,tags -Xlog:safepoint -Xlog:gc+heap=debug
关键要看三类信息： - 每次 GC 类型（Young GC / Mixed GC / Full GC）、耗时（尤其是 STW 时间） - 堆各区域前后大小（Eden、S0/S1、Old 使用量变化） - 是否频繁出现 `Allocation Failure` 或 `Concurrent Mode Failure`（CMS）/ `to-space exhausted`（G1）/ `ZUnmap` 高频（ZGC）日志里出现 Full GC (Ergonomics) 或连续多次 Young GC 后老年代陡增，基本锁定对象过早晋升或内存泄漏。
盯住三个核心指标，别被“调优参数大全”带偏
不用记几十个 JVM 参数，先盯死这三个： - GC 频率：Young GC 是否 > 10 次/秒？说明 Eden 太小或对象生命周期长 - 老年代增长速率：每分钟增长 > 50MB？大概率有缓存未清理、监听器未注销、静态集合膨胀 - STW 时间占比：单次 Full GC > 200ms 或 Young GC 平均 > 50ms，需立即干预（不是换收集器，先看是不是大对象直接入老年代）用工具验证，而不是凭经验猜
- jstat：实时看 GC 统计（`jstat -gc -h10比如发现 org.springframework.context.support.ApplicationListener 实例数每小时涨 200 个，基本就是监听器注册后没 remove。
立即学习“Java免费学习笔记（深入）”；
从代码里找“回收不了”的真正原因
GC 不回收，90% 不是算法问题，而是你写的代码让对象“活该活着”： - 缓存用了 `static Map` 但没配淘汰策略 - 回调注册了 `addXXXListener(this)`，却没在销毁时 `removeXXXListener(this)` - Stream 中用了 `collect(Collectors.toMap(...))` 返回 `HashMap`，但 key 是可变对象（hashCode 变化导致无法 remove） - 日志框架中 `logger.info("user: {}, order: {}", user, order)` 的占位符在高并发下触发 StringBuilder 缓存膨胀这些都不是 GC 机制缺陷，而是引用链没断——对象明明业务上已无用，却被栈、静态变量、ThreadLocal、监听器列表牢牢拽着。
不复杂但容易忽略。
