GC overhead limit exceeded 表明GC耗时超98%但仅回收＜2%内存，核心原因是内存泄漏、堆配置过小、代码低效或GC策略不当；需结合GC日志、堆转储、jstat等工具定位泄漏点，而非误判为死锁。

垃圾回收日志里的“超限警报”本身不直接反映死锁，但能高效暴露慢性内存泄漏——而后者在分布式系统中常被误判为死锁。关键在于区分表象与根因：线程卡住、接口超时、资源耗尽，未必是线程互相等待，更可能是堆内存持续增长→GC压力飙升→线程停顿加剧→看起来像死锁。

盯紧三类超限日志信号

不是所有“GC overhead limit exceeded”都等价。以下三类出现任意一种，优先排查泄漏而非死锁：

• GC overhead limit exceeded + 老年代使用率＞90%且Full GC后几乎不回落（例如：Metaspace: 245120K→245088K）——说明对象或类无法卸载，不是线程卡死，是引用链未断
• 频繁触发 Metadata GC Threshold，伴随Classes unloaded = 0——动态代理类堆积（如Spring AOP切面过宽、CGLIB反复生成新类），类加载器未释放，和死锁无关
• 同一时间窗口内，多节点日志同步出现 GC overhead + RPC超时 + 心跳丢失——不是单点死锁，而是共性泄漏（如共享缓存未设过期、全局静态Map持续put）拖垮整个服务网格

用时间线交叉验证排除死锁假象

把GC日志时间戳和业务日志对齐，看异常是否随负载节奏变化：

• 若“GC overhead”在每小时定时任务启动后准时爆发，且jstack显示大量线程处于BLOCKED但持有同一把锁——需查代码逻辑；但若线程实际处于WAITING（如TIMED_WAITING on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject），大概率是下游响应慢导致上层线程积压，根源仍是内存不足引发的GC停顿延长
• 若多个微服务节点在相同部署版本上线后，同步出现GC overhead频率陡增，应立刻检查公共依赖（如统一日志框架、配置中心客户端、RPC序列化器）是否存在已知泄漏问题

配合jstat和堆快照做闭环确认

单靠日志易误判，必须用运行时指标交叉印证：

• 执行jstat -gc <pid>，观察MU（Metaspace Used）和OU（Old Used）是否持续单向上涨，MC/OC容量是否被动扩容——这是泄漏的铁证
• 执行jstat -class <pid>，若loaded类数只增不减，unloaded长期为0，基本锁定类加载器泄漏，与线程状态无关
• 用jmap -dump抓两个间隔5分钟的堆快照，用MAT比对“dominator tree”，重点看java.util.HashMap、org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor等高频泄漏类型实例数是否翻倍