Java内部类访问局部变量需为final或effectively final，根本原因是栈帧销毁后局部变量不复存在，而内部类对象存活于堆中；编译器通过值拷贝到隐式final字段来规避生命周期错位，final确保副本与原始值语义一致。
Java内部类（尤其是局部内部类和匿名内部类）访问方法内的局部变量时，该变量必须是 final 或 effectively final，根本原因不在语法强制，而在 JVM 内存模型与对象生命周期之间的客观矛盾——以及 Java 为保障变量一致性所采取的编译期机制。
栈与堆的生命周期错位
局部变量存于方法的栈帧中，方法执行结束，栈帧弹出，变量即销毁；而内部类实例作为对象，分配在堆内存中，可能长期存活（比如注册为监听器、提交到线程池、作为回调被异步调用）。若允许内部类直接引用一个“随时会消失”的栈上变量，运行时必然出现不可预测行为甚至崩溃。
- 编译器无法让堆中的对象实时追踪栈上已消亡的地址
- JVM 不支持跨栈帧的变量引用，这是内存隔离的基本原则
- 所谓“访问局部变量”，其实是编译器制造的语义幻觉
编译器的解决方案：值拷贝 + 隐藏字段
Java 编译器在生成字节码时，会把被内部类引用的局部变量值（或引用）复制一份，作为内部类的一个隐式 final 字段，并通过构造器传入。例如：
原始代码：
立即学习“Java免费学习笔记（深入）”；
void method() {<br> final String msg = "done";<br> new Thread(() -> System.out.println(msg)).start();<br>}
编译后等效伪代码（内部类视角）：
class $1Thread implements Runnable {<br> private final String val$msg;<br> $1Thread(String msg) { this.val$msg = msg; }<br> public void run() { System.out.println(val$msg); }<br>}
- 这个
val$msg是编译器自动生成的私有字段，不可见但真实存在 - 它在内部类实例创建时就被初始化，之后永不改变
- 外部方法中的
msg和内部类里的val$msg是两个独立存储位置
Final 的本质作用：保证副本与原始值逻辑一致
final 不是为了“禁止修改”，而是向编译器提供一个确定性承诺：该变量一旦初始化，其值（基本类型）或引用目标（引用类型）不会变更。这样编译器才能安全地执行拷贝，并确保两个副本在语义上始终等价。
- 对基本类型：拷贝的是数值本身，final 保证外部不会改写，副本值恒定
- 对引用类型：拷贝的是引用（即对象地址），final 保证引用不指向别处；对象内部状态仍可变
- 若不加 final，外部修改原变量，内部类副本就变成“过期快照”，引发数据不一致
Effectively final 是 Java 8 的实用优化
Java 8 引入 effectively final，只要局部变量在声明后未被重新赋值，即使没写 final 关键字，编译器也接受。这不是放松约束，而是自动识别“事实不可变”。
- 以下属于 effectively final：
String s = "ok"; Runnable r = () -> System.out.println(s); - 以下破坏 effectively final：
int x = 0; x++; // 重赋值 → 编译失败 - if/for 中多分支赋值（如
String s; if (a) s="A"; else s="B";）也不满足
