Lambda表达式引用的局部变量必须是effectively final，因其本质是值拷贝而非引用共享，需避免数据不一致与栈帧销毁后的生命周期冲突；JVM在创建Lambda时快照变量值并存为隐式字段，故要求该值不可变。
Java 中 Lambda 表达式引用的局部变量必须是 effectively final（实际上为 final），不是因为语法强制要求写 final 关键字，而是因为 JVM 在底层需要确保该变量在 Lambda 创建后不会被修改——否则会引发数据不一致或生命周期错乱问题。
变量捕获的本质是“值拷贝”，不是引用共享
Lambda 表达式在编译后会被翻译成私有静态方法（或通过 invokedynamic 动态引导），而它所访问的局部变量，**不会直接持有对栈帧中原始变量的引用**。JVM 实际上是在 Lambda 对象创建时，把那个局部变量的当前值“快照”下来，作为 Lambda 内部的一个隐式字段保存（类似匿名内部类的构造器传参）。这本质上是值传递。
- 例如：
int x = 10; Runnable r = () -> System.out.println(x);，Lambda 并没有绑着栈里的x，而是记住了当时x == 10这个值。 - 如果允许后续修改
x（比如x = 20;），那 Lambda 内部看到的还是 10，外部逻辑却以为“同一变量”，容易产生理解偏差和 bug。
避免生命周期冲突：局部变量可能已“消亡”
局部变量存在于方法栈帧中，方法执行结束，栈帧弹出，变量就不可访问了。但 Lambda 对象可能被返回、存储、延迟执行（比如提交到线程池），它的生命周期远长于定义它的方法。
- 若允许捕获可变局部变量，JVM 就得把该变量从栈上“挪”到堆上（即逃逸分析+栈上分配优化失效），还要维护多线程下的可见性与同步——这违背了局部变量的语义，也大幅增加实现复杂度。
- 强制 effectively final，等于告诉 JVM：“这个值不会再变”，于是可以安全地做一次拷贝，无需担心后续修改和内存可见性问题。
为什么允许“effectively final”而非必须声明 final？
Java 8 起放宽了语法限制：只要变量在初始化后**从未被重新赋值**，即使没写 final，编译器也接受。这是为了提升可读性和编码便利性。
- ✅ 合法：
int x = 5; Runnable r = () -> System.out.println(x); - ❌ 非法：
int x = 5; x = 10; Runnable r = () -> System.out.println(x);（编译报错：local variables referenced from a lambda expression must be final or effectively final） - 注意：实例字段、静态字段无此限制，因为它们本就在堆上，生命周期天然匹配 Lambda 对象。
对比匿名内部类，加深理解
匿名内部类也有同样限制（Java 7 及以前就要求显式 final），Lambda 继承了这一设计原则，只是语法更宽松。二者底层机制高度相似：都是通过构造器把外部变量值传入并保存为内部类/合成类的字段。
- 区别在于：Lambda 更轻量，不一定生成独立 class 文件；而匿名内部类必定生成
Outer$1.class这样的文件。 - 核心思想一致：**捕获的是值，不是变量本身；安全的前提是值不变。**
