根本原因是生命周期不一致和变量捕获机制：局部变量存于栈，方法结束即销毁，而匿名内部类对象在堆中可能长期存活，JVM需通过值拷贝确保其引用的局部变量稳定；final或effectively final强制该值不可变，避免副本与原始值不一致。
java 中匿名内部类访问局部变量必须是 final 或 effectively final，这不是语法随意设的门槛，而是由变量生命周期和内存模型决定的硬性保障。理解这一点，就能看清“捕获”本质——它不是共享引用，而是值的一次性复制。
为什么局部变量必须 final？根源在栈与堆的分离
方法内的局部变量存在栈帧中，方法执行完就销毁；而匿名内部类对象创建在堆上，可能被长期持有（比如作为回调、线程任务、监听器）。如果允许它直接读写一个即将消失的栈变量，程序逻辑必然错乱。
- JVM 的解法是：编译时把该局部变量的当前值（或引用）拷贝一份，塞进匿名内部类的私有字段里
- 这个拷贝动作只发生一次，在内部类构造时完成
- 如果原始变量后续还能改，副本就跟不上了——final 就是为了锁死这个值，确保拷贝前后始终一致
“捕获”其实是值拷贝，不是引用共享
你写的 add(index) 看似在用外部变量，实际运行时，匿名内部类里根本没 index 这个变量名。反编译后会看到类似 val$index 的私有字段，它的值来自编译期确定的那个瞬间。
- 对基本类型（如 int），拷贝的是数值本身（例如 5 → 复制出另一个 5）
- 对引用类型（如 String、ArrayList），拷贝的是引用地址，指向堆中同一个对象（对象内容仍可变）
- 所以 final 保证的是“引用不换”，不是“对象不可变”
Java 8+ 的 effectively final 是怎么工作的？
编译器会在编译阶段静态扫描：只要某个局部变量从声明起就没被重新赋值过，哪怕没写 final 关键字，也自动当作 final 处理。
- 例如：
int x = 10;后再没出现x = ...，那Runnable r = () -> System.out.println(x);就合法 - 一旦放开
x = 20;，编译立刻报错：“x is not effectively final” - 这种机制让代码更简洁，但底层逻辑没变——还是值拷贝，还是生命周期隔离
绕过限制的常见做法及其真实含义
当真需要在内部类中“修改”外部状态时，不能靠打破 final，而是要把可变性转移到堆上：
立即学习“Java免费学习笔记（深入）”；
- 用数组：
final int[] holder = {0};—— 数组引用不变，holder[0]++改的是堆中对象的内容 - 用原子类：
final AtomicInteger counter = new AtomicInteger(0); - 提升为成员变量：
this.count直接访问，因为它本就在堆中，生命周期由外部类实例管理
这些都不是在“绕过 final”，而是在顺应 JVM 的设计逻辑：把需要长期存活、可变的数据，放在它该待的地方——堆。
