java 8后局部变量只需effectively final即可被内部类捕获，即声明初始化后未被重新赋值；编译器自动推断并复制值到隐式字段，避免生命周期冲突，修改需通过可变容器实现。
Java 8 后，内部类（含匿名内部类和 Lambda）捕获局部变量不再强制要求显式写 final，只要变量是 effectively final（事实不可变）即可——即定义后未被重新赋值。这并非放宽语义，而是编译器自动推断的语法优化，底层机制完全一致。
什么是 effectively final？
一个局部变量若满足以下条件，即为 effectively final：
- 声明时初始化，之后从未被重新赋值（基本类型值不变，引用类型地址不变）
- 即使没加
final关键字，编译器也视其为 final - 一旦在后续代码中修改（如
i++、str = "new"），立即触发编译错误：“Variable used in lambda expression should be final or effectively final”
为什么必须 effectively final？
根本原因是生命周期错位：
- 局部变量存于栈帧中，方法执行结束即销毁
- 内部类对象存活于堆上，可能远超原方法生命周期
- 编译器通过“值复制”解决该问题：把变量当前值拷贝为内部类的隐式合成字段（如
val$count） - 若允许修改，副本与原始值将不一致；而同步更新既不可行（栈帧已销毁），也违背简洁设计原则
实战中如何安全使用？
当需要在内部类中“模拟可变状态”时，不能改变量本身，但可改其指向对象的内部内容：
- 用
int[] count = {0};→ 改count[0]++ - 用
AtomicInteger count = new AtomicInteger(0);→ 调用count.incrementAndGet() - 自定义包装类：
class Box { int value; }，传入Box box = new Box();，再改box.value = 1; - 避免误用
final List<string> list = new ArrayList();</string>并以为“集合不可变”——list.add()合法，因为只改内容，未改引用
成员变量 vs 局部变量捕获的区别
这点常被混淆：
- 成员变量可直接访问（如
this.flag或OuterClass.this.name），走的是引用传递，依赖外部实例生命周期，无需 final 约束 - 局部变量必须 effectively final，走的是值复制，与外部栈帧解耦
- Lambda 表达式与匿名内部类底层一致，都生成带
val$xxx字段的合成类，只是语法更简洁
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
