根本原因是JVM为保障线程安全、内存一致性与生命周期正确性，强制Lambda通过值拷贝捕获局部变量；因栈帧销毁后变量失效，必须确保拷贝值不可变，故要求final或effectively final。
Java 中 Lambda 表达式访问的局部变量必须是 final 或 effectively final，根本原因不是语法限制，而是 JVM 为保障线程安全、内存一致性和生命周期正确性所作的底层设计约束。
变量捕获本质是值拷贝，不是引用共享
Lambda 并不持有对方法栈帧中原始局部变量的实时引用。JVM 在创建 Lambda 实例时，会把当时该变量的值“快照”下来，作为 Lambda 内部的一个隐式字段保存（类似匿名内部类通过构造器传参）。这属于值传递。
- 例如：
int x = 10; Runnable r = () -> System.out.println(x);，Lambda 记住的是 x == 10 这个值，而非栈上那个可变的x变量 - 如果允许后续修改
x = 20;，Lambda 内部仍输出 10，外部逻辑却可能误以为“看到的是同一个变量”，导致语义混淆和 bug
避免栈帧销毁后访问失效内存
局部变量存在于方法的栈帧中，方法执行结束，栈帧弹出，变量即不可访问。但 Lambda 对象可能被返回、缓存、提交到线程池延迟执行——它的生命周期远长于定义它的方法。
- 若允许捕获可变局部变量，JVM 就不得不将变量从栈“提升”到堆（逃逸分析干预），并额外处理多线程下的可见性与同步，大幅增加实现复杂度
- 强制 effectively final，等于向 JVM 承诺：“这个值不会再变”，于是可安全完成一次拷贝，无需担心后续修改和内存可见性问题
防止异步执行时的数据不一致
Lambda 常用于并发场景（如 stream().parallel()、CompletableFuture、线程池任务）。若外部变量在 Lambda 创建后被修改，不同线程看到的可能是不同时间点的值副本，造成结果不可预测。
立即学习“Java免费学习笔记（深入）”；
- 比如循环中直接用
for (int i = 0; i < 10; i++) pool.submit(() -> process(i));，所有任务都可能读到i == 10（循环结束后的最终值） - 正确写法是引入一个 effectively final 的中间变量：
for (int i = 0; i < 10; i++) { int idx = i; pool.submit(() -> process(idx)); }
为什么允许 effectively final 而非强制写 final？
Java 8 放宽了语法要求：只要变量初始化后从未被重新赋值，编译器就自动视其为 final，无需显式加 final 关键字。
- ✅ 合法：
String name = "Alice"; list.stream().map(x -> name.length()); - ❌ 非法：
String name = null; if (ok) name = "Alice"; list.stream().map(x -> name.length());（name被二次赋值） - ⚠️ 注意：修改对象内部状态（如
list.add("x")、user.setName("Bob")）不违反规则，因为变量本身（引用地址）未变
