匿名内部类访问的局部变量必须是final或“事实final”，因为编译器会将其值复制为内部类的私有字段以保障生命周期安全和数据一致性。
Java 中匿名内部类能访问的局部变量必须是 final（或“事实 final”，即未被重新赋值），这不是语法随意规定，而是编译器为保障数据一致性所采取的机制——它会把该变量“复制一份”到内部类中作为自己的字段。理解这一点，关键在于看清编译器干了什么，而不是死记规则。
为什么必须是 final？本质是生命周期与副本隔离
方法中的局部变量存在栈上，方法执行完就销毁；而匿名内部类对象可能在堆上长期存活（比如作为回调被其他线程持有）。如果允许内部类直接读写原始局部变量，就会出现“变量已消失但对象还在用”的危险，或引发多线程下的可见性问题。
编译器的解法很务实：不让你改，就给你一个安全快照。
- 当你声明
final int x = 10;，编译器在生成的匿名内部类字节码中，悄悄加了一个私有字段（如val$x） - 构造该内部类实例时，把当时
x的值拷贝进去，后续所有访问都指向这个副本 - 你无法再给
x赋新值，是因为编译器禁止“看起来在改原变量，实际只改了副本”这种语义错觉
反编译验证：亲眼看见编译器生成的副本字段
写一段典型代码：
（示例）void test() {<br> final String msg = "hello";<br> new Thread(() -> System.out.println(msg)).start();<br>}
用 javac 编译后，用 javap -c -p YourClass$1.class 查看匿名内部类（假设是 YourClass$1）：
- 你会看到类似
final java.lang.String val$msg;的字段声明 - 在构造方法里有
aload_0; aload_1; putfield #2 // Field val$msg:Ljava/lang/String;—— 这就是在存副本 - lambda 体内的
println(msg)实际翻译为getfield #2，读的是副本，不是原栈变量
“事实 final”是怎么被识别的？编译器静态检查
从 Java 8 开始，只要局部变量在初始化后没被再次赋值，即使没写 final 关键字，也允许在匿名内部类/lambda 中使用。这叫“effectively final”。
编译器在编译期做的是**控制流分析**：扫描整个作用域，确认该变量没有出现在任何赋值语句的左边（= 左侧）。
- ✅ 允许：
String s = "ok"; new Runnable(){ public void run(){ System.out.println(s); } }; - ❌ 报错：
String s = "a"; s = "b"; ... println(s);→ 编译失败：“variable is accessed from within inner class and must be final or effectively final”
常见误区与实战提醒
很多人以为“加 final 是为了线程安全”，其实不是核心原因；也不是“内部类共享变量”，而是“单向快照”。真正要注意的是：
- 副本是值拷贝：对基本类型是数值复制；对引用类型是地址复制（副本和原变量指向同一对象），所以对象内部状态仍可变
- 别试图绕过限制：用数组
final String[] holder = {"x"};或包装类来“伪修改”，虽可行但掩盖了设计意图，易引发维护困惑 - 现代写法优先用 lambda：它复用同一套“effectively final”规则，且编译器优化更成熟，字节码更简洁
