局部类通过编译器生成私有字段并构造时传入值或引用，将 effectively final 变量“搬家”到堆上与实例绑定共存亡；修改其指向对象内部状态可绕过 final 限制。
局部类捕获 effectively final 变量，是理解闭包中变量生命周期延伸最直观的实战入口。它不依赖语法糖或运行时魔法，而是通过编译器生成的隐式引用关系，把本该随方法栈帧销毁的局部变量“固定”在堆上——只要局部类实例还活着，那个变量就活得好好的。
为什么必须是 effectively final？
这不是为了限制你写代码，而是 JVM 在做一件严肃的事：确保数据一致性。
- 局部变量存在栈上，方法一返回就没了；局部类对象却在堆上，可能作为回调、线程任务长期存活
- 如果允许修改原始变量，而局部类里用的是编译时拷贝的旧值，两边就会“失联”，结果不可预测
- 加 final（或保持 effectively final）等于告诉编译器：“这个值/引用从诞生起就不会变”，它才敢放心地把值或引用复制进局部类的私有字段
局部类如何延长变量生命周期？
关键不是“延长”，而是“绑定”。编译器会悄悄做两件事：
- 为每个被捕获的局部变量，在局部类内部生成一个同名私有字段（比如
final String msg→ 局部类里多出private final String val$msg） - 在局部类构造时，把外部变量的值（基本类型）或引用（对象类型）传进去并赋给这个字段
- 局部类后续所有访问，都走这个字段，完全脱离原始栈帧
所以变量没被“延长”，是它的值或引用被“搬家”到了堆上，和局部类实例绑在一起，共进退。
实战中怎么观察生命周期变化？
写个带日志的小例子，就能看清变量何时真正被回收：
- 定义一个简单类
Counter，重写finalize()或用PhantomReference监听回收 - 在方法中创建
final Counter c = new Counter("local"); - 声明一个局部类，访问
c，再把它赋给一个静态字段（模拟长生命周期持有） - 方法执行完，手动触发 GC —— 你会发现
c没被回收；只有把静态引用清空后，它才会真正释放
这说明：局部类实例持有对 c 的强引用，GC 不敢动它。
常见陷阱与绕过方式
想在局部类里“改状态”？不能动 final 变量本身，但可以动它指向的对象内部：
- 用
int[] arr = {0};，然后在局部类里写arr[0]++ - 用
AtomicInteger counter = new AtomicInteger(0);，调用counter.incrementAndGet() - 自定义一个包装类：
class Box { int value; }，局部类里改box.value = 1
这些方案都利用了“引用 final，内容可变”的特性，既满足编译要求，又保留了状态更新能力。
