根本原因是生命周期不一致和变量捕获机制：局部变量存于栈，方法结束即销毁，而匿名内部类对象可能长期存活，JVM需确保其引用的局部变量值稳定可复制。
Java 中匿名内部类访问局部变量必须用 final（或“事实上 final”）修饰，根本原因在于**生命周期不一致**和**变量捕获机制**——局部变量存于栈上，方法执行完就销毁；而匿名内部类对象可能在方法结束后仍存活，JVM 需要确保它所引用的局部变量值稳定、可安全复制。
为什么必须是 final？——避免数据不一致
如果允许修改非 final 的局部变量，会出现两个独立副本：
- 方法栈帧里的原始变量，随方法结束而消失
- 匿名内部类对象中保存的该变量的一个“快照”副本（编译时自动复制）
若允许后续修改原始变量，内部类看到的仍是旧值，逻辑错乱且难以排查。加 final 强制只读，从语法上杜绝了这种不一致。
Java 8 之后为什么可以不写 final？——“事实上 final”语义
Java 8 引入了“effectively final”概念：只要局部变量在初始化后**从未被重新赋值**，即使没显式写 final，编译器也允许匿名内部类访问。
例如：
int x = 10; // 没写 final，但只赋值一次Runnable r = () -> System.out.println(x); // 合法
// x = 20; // 若放开这行，编译报错：x is not effectively final
本质是“值捕获”，不是“引用共享”
匿名内部类访问的不是局部变量本身，而是编译期生成的、与之同名的私有字段，并在构造时把局部变量的当前值拷贝进去。所以：
- 它拿到的是一个独立的值副本，跟原变量内存地址无关
- 修改原变量不影响内部类中的副本（反之亦然）
- final 保证这个“拷贝动作”发生时值已确定且不会变
替代方案：用包装类或实例变量绕过限制
真需要修改值时，可借助以下方式（但需注意线程安全）：
- 使用数组：final int[] holder = {0}; —— 数组引用不变，内容可改
- 自定义容器类：final AtomicInteger counter = new AtomicInteger(0);
- 将变量提升为外部类的成员变量（不再是局部变量）
这些做法本质上是把“可变状态”转移到堆上，由对象生命周期管理，避开栈变量的生命周期约束。
