匿名内部类只能访问final或“等效final”的局部变量，因其生命周期长于方法栈帧，需通过值/引用拷贝保证数据一致性；修改外部变量会导致副本不同步，故Java强制不可变承诺。
Java 中匿名内部类能访问的局部变量必须是 final 或“等效 final”（effectively final），这不是语法糖限制，而是由变量生命周期、内存模型和数据一致性共同决定的底层约束。
为什么匿名内部类不能修改外部局部变量
匿名内部类对象的生命周期可能远长于它所处的方法栈帧。方法执行完后，栈上的局部变量（比如 int x = 100）就销毁了，但内部类实例仍存活在堆上，并可能通过回调、线程、事件监听等方式被后续调用。如果允许它“看到”一个可变的局部变量，就会出现两个独立副本：一个在原方法栈里，一个被内部类拷贝到自己的字段中。一旦外部改了 x，内部类里的拷贝不会同步更新——这直接破坏一致性，且无法预测。
Java 的解法是：只允许访问 final 变量，这样编译器可在内部类中安全地做一次值拷贝（对基本类型）或引用拷贝（对引用类型），并确保这个拷贝与原始变量在语义上“永远一致”。
- 你写
final int x = 100;，编译后内部类会生成一个隐式字段，比如val$x，初始化为 100 - 你删掉
final但全程没再赋值（effectively final），Java 8+ 也允许——因为行为等价 - 只要你写了
x = 200;，哪怕只在final声明之后、内部类创建之前，编译就报错：无法保证拷贝值与原始值同步
effectively final 是怎么工作的
Java 8 引入 effectively final 并非放宽规则，而是让编译器自动判断“是否真的没被重新赋值”。它不改变本质机制：仍是拷贝 + 不可变承诺。区别只在语法检查阶段。
立即学习“Java免费学习笔记（深入）”；
以下代码合法：
void method() {
int x = 100; // 没有 final，但没再赋值
Runnable r = new Runnable() {
public void run() {
System.out.println(x); // OK：x 是 effectively final
}
};
}
但只要中间插入一句 x = 200;，哪怕在 new Runnable() 之前，编译就失败。不是因为“顺序”，而是因为 x 已失去不可变性保证。
引用类型 final 的常见误解
final List<String> list = new ArrayList<>(); 这个 list 是 final 的，意味着你不能执行 list = new ArrayList<>();，但完全可以用 list.add("a") 修改其内容。匿名内部类拿到的，是这个引用的拷贝，指向同一个堆对象——所以增删改查都生效，也没问题。
真正被禁止的，永远只是“重新赋值”这个动作本身：
- 基本类型：值不能变（
final int x→ 不能x = 101） - 引用类型：引用地址不能变（
final Object o→ 不能o = new Object()） - 对象内部状态：不在 final 约束范围内，可自由修改
绕过 final 的反射操作不解决实际问题
用反射去掉 final 修饰符（如修改 modifiers 字段），确实能让 JVM 允许运行时重赋值，但这只影响该变量本身的可见性，**不会让内部类持有的拷贝同步更新**。也就是说，你改了外部变量，内部类里还是旧值；或者你改了内部类字段（如果能访问），外部方法也看不到——两边彻底脱钩。这种操作只适合调试或 hack 场景，不能用于修复设计问题。
真正需要修改外部状态时，应改用包装容器，比如 AtomicInteger、final int[] x = {100}，或自定义 holder 类。它们把“可变性”显式封装在对象内部，而非试图突破局部变量的生命周期边界。
