内存泄漏与溢出需日常预判监控而非事后排查；先区分类型（堆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 使用或递归深度。
基础三板斧：日志、工具、快照缺一不可
不依赖高级平台也能完成有效初筛：
- 启动时加参数开启 GC 日志：-Xloggc:gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps，观察 GC 频率、耗时、前后堆大小变化；
- 用 jstat -gc <pid> 实时查看各代内存使用与 GC 统计，重点关注 YGC 次数激增或 FGCT 持续增长；
- 触发堆转储：jmap -dump:format=b,file=heap.hprof <pid>，再用 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 在线诊断，避免重启就能获取实时内存视角。
