局部内部类访问局部变量的本质是编译器隐式复制变量值或引用作为其私有字段，故变量需effectively final以保证一致性；验证方式为通过静态引用延长内部类生命周期并观察对象GC行为。
局部内部类访问方法局部变量，并不是让变量“活久一点”，而是编译器在生成字节码时，把变量的值或引用**复制一份，作为内部类的私有字段**存进堆中——这个过程叫“隐式 copy”。理解这一点，就抓住了 Java 闭包模拟的本质。
为什么必须是 effectively final？
局部变量存在栈上，方法一结束，栈帧销毁，原始变量就没了；而局部内部类实例可能被传给线程、监听器或缓存起来，长期存活在堆上。如果允许修改原始变量，内部类用的却是编译时拷贝的老值，两边就会不一致。
加 final 或保持 effectively final（初始化后不再赋值），等于向编译器承诺：“这个值/引用不会变”。它才敢放心地把值（基本类型）或引用（对象类型）拷贝进内部类，生成类似 val$timeout、val$config 这样的私有字段。
如何验证“隐式 copy”真实发生？
写个可观察的小实验：
- 在方法里创建一个对象，比如
Counter c = new Counter("local") - 定义局部类并访问
c，再把它赋给一个 静态字段（模拟长生命周期持有） - 方法执行完，手动触发 GC ——你会发现
c没被回收 - 只有清空那个静态引用后，
c才真正释放
这说明：局部类实例持有了对 c 的强引用，变量不是“延长寿命”，而是“换地方住”了——从栈搬到了堆，和内部类实例绑定共存亡。
想改状态？别动变量，动它里面的内容
final 限制的是变量本身不能再赋值，但不禁止修改其所指向对象的内部状态。常用安全绕过方式：
- 用
int[] arr = {0}，然后在局部类里写arr[0]++ - 用
AtomicInteger counter = new AtomicInteger(0)，调用counter.incrementAndGet() - 自定义包装类：
class Box { int value; }，在局部类里改box.value = 1
这些方案都利用了“引用 final，内容可变”的特性，既满足编译约束，又保留了状态更新能力。
警惕隐式 copy 带来的内存泄漏
局部类捕获的每个局部变量（尤其是大对象：Bitmap、byte[]、完整 DTO、Activity 实例等），都会被强引用住。一旦局部类实例被注册为全局监听器、放进静态缓存或线程池，这些对象就无法被 GC 回收。
实战建议：
- 只捕获真正需要的字段，避免直接捕获整个外部类实例或大对象
- 若只需某个 ID 或 flag，显式构造传入，而不是依赖闭包捕获
- 在 Android 等场景中，必要时用
WeakReference包装外部对象，或在销毁时主动置 null
