内存泄漏与溢出需日常预判监控而非事后排查；先区分类型（堆oom表现为full gc频繁且堆使用率>90%，泄漏表现为老年代缓慢上涨且gc后不回落），再用gc日志、jstat、jmap三板斧初筛，结合mat分析引用链定位问题，最后通过防御性实践（如自动堆转储、规范缓存、注册/注销配对）提前拦截。
内存泄漏和溢出不是“出了问题才去查”，而是日常开发和上线运维中必须具备的预判、监控与快速定位能力。掌握基本排查手段是底线，而建立系统性分析思路才是进阶关键。
从现象反推：先分清是泄漏还是溢出
很多同学一看到 OOM 就直接翻 GC 日志，其实第一步应快速判断类型：
- 内存溢出（OOM）：JVM 申请不到足够堆内存（如 java.lang.OutOfMemoryError: Java heap space），通常伴随 Full GC 频繁但回收效果差，堆使用率长期 >90%；
- 内存泄漏（Leak）：对象本该被回收却一直被强引用持有，导致可用堆空间持续减少——表现为老年代占用缓慢上涨、GC 后无法回落、服务运行越久越慢；
- 注意：Metaspace OOM、Direct Memory OOM、线程栈溢出等不属于堆内存问题，需单独排查类加载器、NIO 使用或递归深度。
基础三板斧：日志、工具、快照缺一不可
不依赖高级平台也能完成有效初筛：
Codex Auth Cleaner
下载
一款AI工具，主要用于Monitor and clean up invalid Codex authentication files in CPA. Check quota status, disable files returning 401 errors, and perform dual verification before deletion.，适合需要提升相关任务效率的用户。
- 启动时加参数开启 GC 日志：-Xloggc:gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps，观察 GC 频率、耗时、前后堆大小变化；
- 用 jstat -gc
实时查看各代内存使用与 GC 统计，重点关注 YGC 次数激增或 FGCT 持续增长； - 触发堆转储：jmap -dump:format=b,file=heap.hprof
，再用 VisualVM / Eclipse MAT 分析大对象、支配树（Dominator Tree）、可疑的 GC Roots 引用链。
进阶定位：关注“不该活”的对象和“不该留”的引用
真正耗时的不是找大对象，而是理解为什么它没被回收：
- 检查静态集合（HashMap、List）、缓存（未设过期/大小限制）、监听器/回调注册后未注销、ThreadLocal 未 remove —— 这些是泄漏高发区；
- 留意内部类持有外部类引用、Lambda 表达式隐式捕获、Spring Bean 作用域误配（如 singleton 中注入 prototype bean）；
- 用 MAT 的 “Path to GC Roots” 功能，过滤掉弱/虚引用，聚焦强引用链，逐层收缩怀疑范围，直到定位到业务代码中的具体字段或容器。
防御性实践：把问题挡在上线前
排查是救火，预防才是常态：
- 本地开发阶段启用 -XX:+HeapDumpOnOutOfMemoryError，配合单元测试+压力测试暴露潜在泄漏；
- 关键缓存统一走 Caffeine/Guava Cache，设置 maximumSize 和 expireAfterWrite；
- 所有注册型 API（如 addListener、registerObserver）配套提供 unregister 方法，并在 finally 或 @PreDestroy 中调用；
- 定期用 Arthas 的 monitor、watch、heapdump 在线诊断，避免重启就能获取实时内存视角。
