局部变量必须是 effectively final，因为局部内部类通过值拷贝访问该变量，而 JVM 不支持跨栈帧引用；若变量可变，副本与原始值语义不一致，导致逻辑错误。
被局部内部类访问的局部变量必须是 effectively final（有效 final），根本原因不是语法限制，而是 JVM 内存模型与对象生命周期之间不可调和的矛盾——栈上变量短命，堆上对象长存，Java 用“值拷贝”来桥接二者，而 effectively final 是确保拷贝安全、语义一致的必要前提。
栈和堆的生命周期天然错位
局部变量存在方法的栈帧里，方法一返回，栈帧弹出，变量立即销毁；而局部内部类实例是对象，分配在堆中，可能被监听器、线程、回调等长期持有。如果允许它直接引用一个即将消失的栈地址，运行时必然出错。JVM 不支持跨栈帧的实时变量引用，这是内存隔离的底线。
编译器实际做的是“值捕获”，不是“变量共享”
当你写：
void method() {
String msg = "ok";
new Thread(() -> System.out.println(msg)).start();
}
编译器会悄悄生成一个类似这样的内部类：
class $1Thread implements Runnable {
private final String val$msg;
$1Thread(String msg) { this.val$msg = msg; }
public void run() { System.out.println(val$msg); }
}
也就是说，内部类拿到的不是 msg 本身，而是它在构造那一刻的**快照副本**。这个副本独立存储、永不更新。
为什么必须 effectively final？——避免副本“过期”
- 如果变量可变，比如
int count = 0; count++;，外部改了值，但内部类里还是旧副本，逻辑就错乱了 - effectively final 要求变量从初始化后**从未被重新赋值**，这样编译器才能确信：拷贝发生时，值已稳定，副本与原始值在语义上始终等价
- 对基本类型，保证数值不变；对引用类型，保证引用不指向别处（对象内容仍可修改）
Java 8+ 的 effectively final 是编译期静态检查
你不用显式写 final，只要满足“只赋值一次”，编译器就自动认可。例如：
String s = "hello";
Runnable r = () -> System.out.println(s); // 合法
但一旦出现 s = "world";，编译直接报错："s is not effectively final"。这不是运行时行为，而是编译器在字节码生成前就完成的确定性校验。
