答案是GC overhead limit exceeded错误本质是GC效率严重下降，表现为频繁高耗时GC却回收极少内存，通常由内存泄漏或大量长存活对象导致；需通过开启详细GC日志、jstat监控OU/YGC/FGC指标、分析堆转储定位泄漏源。
这个错误不是内存真的不够，而是 JVM 花了太多时间做 GC 却回收不了多少内存，触发了 JVM 的保护机制。本质是 GC 效率严重下降，通常说明堆里存在大量存活对象或内存泄漏。
看 GC 日志确认是否真卡在 GC 上
启动时加参数开启详细 GC 日志，例如：
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:gc.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=10M
观察日志中是否出现连续多次 Minor GC / Full GC，每次耗时高（比如几百毫秒以上）、回收量却很小（如只回收几 MB），且老年代占用持续不降——这就是典型症状。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
立即学习“Java免费学习笔记（深入）”；
用 jstat 快速定位 GC 压力来源
运行中执行：
jstat -gc <pid> 2000（每 2 秒刷新一次）
重点关注这几列：
• OU（Old Used）：老年代已用空间，持续上涨不回落 → 可能有内存泄漏或大对象直接进老年代
• YGC / YGCT：年轻代 GC 次数和总耗时，频繁且耗时高 → 对象存活时间长、晋升快
• FGC / FGCT：Full GC 次数和总耗时，明显增长 → 老年代撑不住了
导出堆快照分析对象分布
触发 OOM 时自动生成堆转储（加参数：-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dump.hprof），或手动用 jmap：
jmap -dump:format=b,file=dump.hprof <pid>
用 VisualVM、JProfiler 或 Eclipse MAT 打开分析：
• 看 Dominator Tree，找占用最大的对象实例或类
• 按 class 查看对象数量和总大小，特别关注业务相关的集合类（如 HashMap、ArrayList）、缓存、监听器、静态引用等
• 检查是否有本该被释放的对象被意外持有（如 ThreadLocal 未清理、内部类持外部类引用、注册监听器没反注册）
检查常见内存泄漏陷阱
• 静态集合类长期持有对象（如 static Map 缓存没设上限或没清理）
• 使用 ThreadLocal 后未调用 remove()，尤其在线程池场景下会累积
• 数据库连接、文件流、网络连接等资源未正确 close，间接导致关联对象无法回收
• 第三方框架使用不当，如某些 ORM 的 session 没关闭、Spring 中 prototype bean 被 singleton bean 引用
