lambda表达式捕获变量是值拷贝而非引用共享，要求局部变量为final或effectively final，以避免数据不一致、生命周期错乱及线程安全问题；jvm在创建lambda时快照变量值并存为隐式字段，确保行为可预测。
因为 Lambda 表达式捕获的是变量的值快照，不是实时引用；要求 final 或等效 final，本质是为了避免数据不一致、线程安全风险和生命周期错乱。
捕获机制是“值拷贝”，不是“变量共享”
Lambda 在编译时会被转为静态方法或通过 invokedynamic 构建函数对象，它访问外部局部变量时，并不会持有对栈帧中原始变量的引用。JVM 会在创建 Lambda 实例时，把当时变量的值（基本类型）或引用（对象）“快照”下来，存为该对象的隐式字段。
- 比如
int x = 5; Runnable r = () -> System.out.println(x);，Lambda 记住的是x == 5这个值，不是栈上那个x变量本身 - 如果允许后续修改
x = 10;，Lambda 内部仍输出 5，而外部逻辑可能误以为“改了就同步”，造成语义混淆
防止栈帧销毁后访问失效内存
局部变量存在方法栈帧里，方法执行完，栈帧弹出，变量就不可访问了。但 Lambda 对象可能被返回、缓存、提交到线程池延迟执行——它的生命周期远长于定义它的方法。
- 若允许捕获可变局部变量，JVM 就得把变量从栈“挪”到堆（逃逸分析强制升级），还要处理多线程下的可见性与同步
- 强制等效 final，等于向 JVM 承诺：“这个值不会再变”，于是可以安全做一次拷贝，无需复杂同步
保障线程安全与行为可预测
Lambda 常用于并发场景（如 stream().parallel()、CompletableFuture）。如果多个线程同时读写同一个局部变量副本，又没有同步机制，就会出现竞态条件或读到脏值。
- 值拷贝 + 不可变约束，天然规避了共享可变状态的问题
- 哪怕变量引用的对象内部状态可变（如
list.add()），只要引用本身不变，就不影响 Lambda 的一致性 - 编译期强制检查，比运行时出错更早暴露问题
为什么允许 “等效 final” 而不强制写 final？
Java 8 引入 effectively final，是语法层面的优化：只要变量初始化后从未被重新赋值，编译器就自动视其为 final。
- ✅ 合法：
int count = 0; list.forEach(x -> System.out.println(count)); - ❌ 非法：
int count = 0; count++; list.forEach(x -> System.out.println(count));（方法体内赋值两次） - 这不是妥协，而是平衡——既守住语义安全底线，又减少冗余关键字，提升可读性
