局部变量必须是 effectively final，因为java通过值拷贝将其作为内部类的私有final字段嵌入字节码，以解决栈变量销毁早于堆对象生命周期导致的悬空引用问题。
被局部内部类访问的局部变量必须是 effectively final（有效 final），不是语法随意设的限制，而是 Java 为解决栈与堆生命周期错位、保障数据一致性所采取的底层机制。
生命周期冲突：栈上变量 vs 堆上对象
局部变量存在方法的栈帧中，方法执行结束，栈帧弹出，变量立即销毁；而局部内部类实例作为对象，分配在堆内存中，可能长期存活（比如被返回、注册为监听器、提交到线程池）。如果允许它直接引用一个“已经不存在”的栈变量，运行时就会出现悬空引用——这在 JVM 内存模型中是严格禁止的。
Java 不支持堆中对象实时追踪栈上已消亡地址，这是内存隔离的基本原则。
编译器的应对策略：值拷贝 + 隐式字段
编译器不会让内部类真正“访问”原始局部变量，而是做了一次性值拷贝：
- 把该局部变量的当前值（基本类型）或引用（对象类型）复制一份；
- 作为内部类的一个私有 final 字段（如
val$xxx）嵌入字节码； - 通过内部类构造器传入并初始化。
你写的这段代码：
String msg = "done";
new Thread(() -> System.out.println(msg)).start();
}
实际等效于编译后生成的伪代码中，内部类持有一个不可变的 private final String val$msg 字段。
为什么必须 effectively final？
effectively final 的本质是：变量在初始化后**从未被重新赋值**。编译器靠这个承诺来确保拷贝动作的安全性：
- 对基本类型：拷贝的是数值本身，final 保证外部不会改写，副本值恒定；
- 对引用类型：拷贝的是对象地址，final 保证引用不指向别处（对象内部状态仍可变）；
- 若允许后续修改原始变量，内部类看到的仍是旧值，逻辑就错乱了——这不是 bug，而是设计上不允许出现的歧义。
Java 8 起不再强制写 final 关键字，但只要你在初始化后给变量重新赋值（哪怕只一次），它就不再是 effectively final，编译直接报错。
哪些情况会破坏 effectively final
以下写法都会导致编译失败：
int count = 0; count++;String s; if (ok) s = "yes"; else s = "no";-
Runnable r = () -> { s = "changed"; };（在内部类里试图修改）
需要可变状态时，可用替代方案：用 final AtomicInteger、final int[] 或提升为成员变量——它们把可变性转移到堆上，由对象生命周期统一管理。
