Java局部内部类通过编译器自动拷贝effectively final的局部变量值（基本类型复制数值，引用类型复制地址）来解决生命周期不匹配问题；非final会导致数据不一致和线程安全问题；需注意强引用引发的内存泄漏风险。
Java 中局部内部类的生命周期问题，核心在于它可能比定义它的方法活得更久，而方法里的局部变量却随方法结束立即销毁。解决思路不是延长局部变量的寿命，而是让内部类“自带一份可用的数据”。
编译器自动拷贝 final 变量值
当局部内部类访问某个局部变量时，只要该变量是 effectively final（Java 8+ 不强制写 final，但初始化后不能重新赋值），编译器就会在生成的内部类字节码中，悄悄添加一个私有字段（如 val$x），把该变量的值复制进去。
- 基本类型：直接复制数值，比如
int x = 10→ 内部类里存一个int val$x = 10 - 引用类型：复制的是引用地址，不是对象本身，所以内部类和原方法指向同一个对象
- 方法执行完、栈帧销毁后，内部类仍可通过自己的字段安全访问这个“副本”
为什么必须 effectively final
如果不是 final 或等效 final，就可能出现不一致问题：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 方法中改了局部变量，内部类副本还是旧值，两边不同步
- 多个线程同时修改局部变量，内部类副本无法反映最新状态，引发竞态
- 编译器无法保证“复制一次就够”，也就无法安全生成字段
需要修改状态怎么办
final 限制的是变量本身不能再赋新值，不禁止修改对象内部状态。常用做法有：
立即学习“Java免费学习笔记（深入）”；
- 用
int[] arr = {0}，内部类调用arr[0]++ - 用
AtomicInteger counter = new AtomicInteger(0)，调用counter.incrementAndGet() - 自定义包装类：
class Box { int value; }，内部类改box.value = 1
注意内存泄漏风险
这种“拷贝引用”的机制会让内部类持有所捕获对象的强引用。如果内部类实例被长期持有（比如注册为全局监听器、存入静态集合），它捕获的对象也会一直无法被 GC 回收。
- 尤其在 Android 中，避免在 Activity 里定义匿名内部类并捕获 Activity 引用
- 必要时用
WeakReference包装外部对象，或手动清理引用
