为什么匿名内部类只能访问 final 或 effectively final 的局部变量
Java 编译器在生成匿名内部类字节码时，会把捕获的局部变量“复制”一份到内部类的合成字段里。这不是引用外部栈帧里的变量，而是拷贝值——所以如果允许修改，就会出现“外部变量变了但内部类里还是旧值”的不一致问题。为避免这种语义混乱，JVM 要求这些变量必须是 final 或 effectively final（即声明后未再赋值），确保拷贝值和原始值始终一致。
注意：这个限制只针对「局部变量」，成员变量（this.field）不受影响，因为它们本来就存在堆上，匿名类持有的是对外部实例的引用。
effectively final 是什么，怎么判断它是否成立
effectively final 指变量虽未显式加 final 修饰符，但在作用域内只被赋值一次。编译器会静态检查，不是运行时判断。
- ✅ 合法：
String s = "hello"; new Runnable() { public void run() { System.out.println(s); } }; - ❌ 编译报错：
String s = "hello"; s = "world"; new Runnable() { public void run() { System.out.println(s); } };→ 报错信息：local variable s is accessed from within inner class; needs to be declared final or effectively final - ⚠️ 注意：哪怕只在 if 分支里赋了两次，也算违反 effectively final，比如
int x; if (cond) x = 1; else x = 2;这种写法会让x失去 effectively final 资格
想在匿名类里“修改”局部变量怎么办
不能真改原变量，但有几种常见绕过方式，各自适用场景不同：
立即学习“Java免费学习笔记（深入）”；
- 用单元素容器：比如
AtomicInteger、int[] arr = {0}、Object[] box = {null}，匿名类里改的是容器内容，不是变量本身 - 改用 Lambda 表达式（Java 8+）：语法更简洁，同样受 effectively final 约束，但 IDE 通常提示更友好
- 提取成成员变量：如果逻辑较重，说明这个变量本就不该是局部的，移到类字段里更合理
- 避免副作用：多数情况下，“想修改”其实是设计信号——考虑把逻辑拆进方法参数或返回值，而不是靠闭包共享可变状态
Java 8 之后还有没有例外情况
没有例外。Java 8 引入 effectively final 后，反而让规则更严格了：以前加 final 是强制语法，现在不加也能过，但一旦你多赋一次值，编译就失败。这其实提升了可读性——你一眼能看出哪些变量被闭包捕获了。
容易忽略的一点：Lambda 和匿名内部类在这条规则上完全一致。很多人以为 Lambda 更“自由”，其实只是编译器帮你省了 final 关键字，底层约束没变。另外，try-with-resources 中声明的资源变量也必须是 effectively final，原理相同，但那是另一个机制了。
