lambda 表达式要求局部变量为 effectively final（初始化后不再赋值），编译期强制检查；它通过值拷贝捕获变量（基本类型拷数值，引用类型拷地址），确保异步/跨线程安全访问。
Java 中 Lambda 表达式本身不改变局部变量的属性，但它会**严格检查并依赖**该变量是否满足 effectively final（实质不可变）条件——一旦变量在 Lambda 定义之后被修改，编译直接报错，不是运行时问题，而是编译期硬性约束。
什么是 effectively final？
一个局部变量只要满足“初始化后不再被重新赋值”，就属于 effectively final。编译器不看你有没有写 final 关键字，只看行为：
- 声明即初始化，后续无任何赋值语句 → 满足
- 先声明为
String s;，再在 if/else 中各赋一次值 → 不满足（哪怕只赋一次，也因存在赋值动作而失效） -
count++、list = newList、循环中反复给i赋值 → 全部破坏 effectively final - 修改对象内部状态（如
list.add("x")、user.setName("A")）→ 不影响，因为变量引用本身没变
Lambda 是如何“捕获”这个变量的？
它不是引用原始栈上那个变量，而是做了一次值拷贝：
- 基本类型：拷贝当前数值（比如
int x = 5，Lambda 里用的就是 5 这个快照） - 引用类型：拷贝的是引用地址（比如
String s = "ok"，Lambda 记住的是指向堆中 "ok" 的那个地址） - 方法执行完、栈帧销毁后，Lambda 仍能安全访问这个副本，因为它已固化在闭包结构里
为什么一改就报错？关键在生命周期和一致性
Lambda 可能异步执行、延迟调用，甚至跨线程运行。如果允许外部修改原变量：
- Lambda 看到的还是旧值，外部逻辑却以为“大家共用同一个变量” → 行为错乱
- JVM 无法保证多线程下该变量的可见性与同步，容易引发竞态
- 局部变量本该随方法结束而消亡，强制要求 effectively final，等于告诉 JVM：“这值稳了，可以放心拷贝到堆上”
常见踩坑写法与对应解法
这些代码都会触发编译错误：
-
String msg = ""; try { msg = api.call(); } catch(e) { msg = "err"; } stream.map(x -> msg.length());→ 改用三元表达式：String msg = success ? api.call() : "err"; -
for (int i = 0; i process(i)); }→ 改成for (int i = 0; i process(idx)); } -
StringBuilder sb = new StringBuilder(); list.forEach(s -> sb.append(s));→ 改用String result = list.stream().collect(Collectors.joining());
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
