内存泄漏是“该还的没还”，指已无用对象被意外持有导致GC无法回收，长期累积推高内存占用；内存溢出是“地方不够用了”，指申请内存时堆等空间不足直接抛OutOfMemoryError，可能是泄漏所致，也可能是单次分配过大或配置不当。
内存泄漏（Memory Leak）和内存溢出（OutOfMemoryError，简称 OOM）常被混淆，但二者本质不同：泄漏是“该还的没还”，溢出是“地方不够用了”。识别清楚才能对症下药。
内存泄漏：资源未释放，积少成多
指程序中已不再使用的对象仍被引用，导致垃圾回收器（GC）无法回收，长期累积占用堆内存。单次泄漏影响小，持续发生会推高老年代使用率，最终可能诱发频繁 Full GC 或间接导致 OOM。
- 典型场景：静态集合类持有 Activity/Context（Android）、未关闭的 IO 流、监听器注册后未反注册、ThreadLocal 存储大对象且线程复用
- 排查方法：用 Android Profiler 或 MAT 分析 Heap Dump，重点关注支配树（Dominator Tree）中异常大的对象及其 GC Roots 引用链；检查是否存在“本该短生命周期却被长生命周期对象持有着”的情况
- 关键判断依据：多次操作后 heap usage 持续上升，且 GC 后回落不明显；泄漏对象实例数随操作次数线性增长
内存溢出：分配失败，直接崩溃
指 JVM 在尝试为新对象分配内存时，堆（或元空间、栈等）已无足够连续空间，抛出 java.lang.OutOfMemoryError。它可能是泄漏的结果，也可能是单次分配过大或配置不合理所致。
- 常见类型：Java heap space（堆满）、Metaspace（类元数据过多，如动态生成大量类）、unable to create new native thread（线程数超系统限制）、Direct buffer memory（堆外内存不足）
- 定位要点：看错误日志中的具体提示；结合 JVM 参数（-Xmx、-XX:MaxMetaspaceSize 等）与实际负载评估是否配置过小；用 jstat 观察 GC 频率与各代使用趋势
- 注意区分：OOM 不等于一定有泄漏——比如一次加载 500MB 图片到内存，即使无泄漏也会 OOM
实战排查逻辑：先定现象，再溯根源
不要一看到 OOM 就查泄漏。应按顺序快速收敛问题范围：
- 看异常堆栈和错误信息——明确是哪类 OOM，发生在什么操作之后
- 观察内存曲线（Android Profiler / VisualVM）——是缓慢爬升（倾向泄漏），还是某次操作后陡升（倾向单点大对象或配置问题）
- 触发几次相同操作，对比 Heap Dump 中对象数量变化——若某类对象实例数稳定增长，高度疑似泄漏
- 检查代码中易出问题的模式：static + Context、Bitmap 复用、RxJava/Flowable 未 dispose、协程作用域未及时取消
预防比修复更有效
很多泄漏其实在编码阶段就能规避：
- 避免 static 持有 Activity/View；Context 优先用 Application Context
- 资源型对象（Cursor、InputStream、Bitmap、HandlerThread）务必显式 close / recycle / quit
- 注册监听/回调后，确保在生命周期结束时反注册（onDestroy/onDetach）
- 使用 WeakReference 包装非强依赖的回调持有者（慎用，需确认业务逻辑允许被回收）
- 上线前开启 StrictMode（Android）或使用 LeakCanary，及早暴露问题
