Java非静态内部类因隐式持有外部类强引用易致内存泄漏，典型表现为堆内存持续增长、老年代回收无效，需通过jstat/jmap+MAT分析引用链并依场景用静态类、WeakReference等解法规避。
Java内部类引发的内存泄漏，核心在于非静态内部类（含匿名类、局部类）隐式持有一个对外部类实例的强引用。当内部类对象生命周期长于外部类时，外部类无法被回收，导致本该释放的大对象持续驻留堆中。排查与解决需紧扣“引用链”和“生命周期错配”两个关键点。
怎么快速识别是不是内部类导致的泄漏
满足以下任意两点，高度怀疑内部类泄漏：
- 堆内存缓慢但持续上涨，Full GC 后老年代使用率不回落，甚至逐次升高
- 堆转储（heap dump）中，大量内部类实例（如
Outer$1、Outer$Inner）持有对大型外部类对象（如Activity、Service、自定义Context或大数据容器）的引用 - 代码中存在将内部类/匿名类赋值给静态字段、缓存、线程池、单例、监听器注册表等长生命周期容器的操作
用工具定位泄漏源头
分三步走，无需重启服务：
- jstat -gc PID：观察老年代（OGCMN/OGCMX/OGC）是否持续增长、FGC 次数飙升、每次耗时超 1s
- jmap -dump:format=b,file=heap.hprof PID：导出堆快照（建议在 Full GC 后立即执行，减少噪声）
-
用 VisualVM / Eclipse MAT 打开 heap.hprof：
- 按类名筛选你的内部类（如
MyService$1），查看其数量和 retained heap - 右键 → “Merge Shortest Paths to GC Roots” → 勾选 “exclude weak/soft references” → 查看谁在强引用它
- 重点看路径中是否出现
static字段、Thread实例、Handler、Timer、AsyncTask等长期存活对象
- 按类名筛选你的内部类（如
常见泄漏场景及对应解法
不是所有内部类都危险，问题出在“错位使用”。以下是高频模式：
立即学习“Java免费学习笔记（深入）”；
-
Handler + 匿名内部类（Android 最典型）：
Activity 中 new Handler() 并 postDelayed 一个 Runnable，Activity 销毁后 Runnable 仍排队等待执行，导致 Activity 无法回收。
✅ 解法：使用静态内部类 + WeakReference；或在 onDestroy() 中 removeCallbacksAndMessages(null) -
线程池提交匿名 Runnable/Callable：
向全局线程池 submit 一个访问外部类成员的 lambda，线程池未关闭，外部类被长期持住。
✅ 解法：改用静态方法或提取为独立类；若必须访问，显式传参而非闭包捕获 -
静态集合缓存内部类实例：
private static Map<String, Listener> listeners = new HashMap<>(); listeners.put("key", new Listener() { ... });
✅ 解法：避免缓存非静态内部类；改用 WeakHashMap；或用接口+独立实现类 -
Timer / ScheduledExecutorService 定期任务：
在内部类中启动周期性任务，未主动 cancel。
✅ 解法：任务对象保存为成员变量，onDestroy/cleanup 时显式 cancel
编码阶段就规避风险
预防比修复成本低得多：
- 优先使用 静态内部类：它不持有外部类引用，适合做工具类、回调封装
- 避免在内部类中直接访问外部类的非 final 成员；如需访问，显式通过参数传入
- 禁止将非静态内部类实例赋值给任何静态变量、单例、Application 级容器
- 使用 Lint（Android）或 SonarQube（Java 后端）配置规则，检测 “Anonymous inner class should not hold reference to outer class” 类警告
- 在构造内部类前，确认其预期生命周期；若超过外部类，必须解耦引用关系
