java内部类安全访问外部类成员依赖编译器生成的package-private桥接方法，而非破坏封装；非静态内部类因持有外部类强引用（this$0）易致内存泄漏，需用静态内部类+weakreference或解耦方案修复。
Java 中内部类访问外部类成员是语言原生支持的机制，但必须理解其原理和边界；内存泄漏排查则需聚焦“隐式强引用”这一核心线索，不能只看代码表象。
内部类怎么安全访问外部类成员
成员内部类（含匿名类）能直接读写外部类的私有字段和方法，这不是绕过封装，而是编译器自动生成 package-private 桥接方法（如 access$100(Outer)）实现的。该方法仅对同包可见，且无法被源码显式调用，封装性未被破坏。
- 前提：必须基于有效的外部类实例创建内部类对象，例如 new Outer().new Inner()；静态上下文中（如 static 方法）不能直接 new 成员内部类
- 字段冲突时，用 Outer.this.fieldName 明确指向外部类字段，避免误操作内部类自己的同名变量
- 静态内部类不持外部类引用，只能访问外部类的静态成员；若需非静态数据，应由外部类主动传入副本或只读视图，而非暴露原始引用
为什么内部类容易引发内存泄漏
非静态内部类（包括匿名类、方法内定义的局部内部类）在编译后会自动添加一个隐藏字段 this 非静态内部类（包括匿名类、方法内定义的局部内部类）在编译后会自动添加一个隐藏字段 this$0，它持有所属外部类的强引用。一旦该内部类实例被长生命周期对象（如线程池、静态集合、Handler 消息队列）持有，外部类就无法被回收。
- 典型场景：Activity 中定义的匿名 Runnable 被 postDelayed，Activity 已 finish，Runnable 却还在消息队列里等着执行
- Lambda 表达式在 Java 8+ 编译后也生成 $1/$2 类，同样带 this$0，具备同等泄漏风险
- 静态内部类无此问题，因为它没有 this$0 字段
如何快速定位内部类引起的泄漏
别等 OOM，要主动抓“不该活却一直活”的对象。关键是通过堆转储分析引用链，确认是否出现 MyActivity$1 → this$0 → MyActivity 这样的路径。
- 用 Android Studio Memory Profiler 或 MAT 打开 .hprof 文件，筛选 Activity 类名，右键 “Merge Shortest Paths to GC Roots” 查看保留路径
- 接入 LeakCanary（如 debugImplementation 'com.squareup.leakcanary:leakcanary-android:2.12'），退出 Activity 后几秒即可收到可视化报告，直接标出 $1 类及其创建位置
- 重点检查 Handler.post、Thread.start、View.setOnClickListener、RxJava subscribe、协程 launch 等异步入口点——这些地方最容易让匿名类脱离宿主生命周期
修复思路不是禁用，而是解耦生命周期
目标不是消灭匿名类，而是切断它对短生命周期宿主的强依赖。
- 将 Runnable/Callback 改为 static 内部类，内部用 WeakReference
持有上下文，使用前判空 - 异步任务中避免直接调用 Activity 的方法或访问其成员变量；改用接口回调、EventBus 或 ViewModel + LiveData 等解耦方案
- 在 onDestroy() 或 onCleared() 中主动 cancel Handler、dispose RxJava Disposable、cancel 协程 Job
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
