Java中局部变量必须final或effectively final，根本原因是Lambda/匿名类捕获的是创建时的值快照，为保障多线程下语义一致性和内存模型安全，需禁止后续修改导致副本与原始值不一致。
这个问题其实混淆了两个层面的概念：虚拟机栈本身并不“捕获”外部引用，真正限制引用可变性的，是语言规范和运行时模型的设计意图——尤其是为了保障线程安全与内存模型一致性。
一、栈上存的是“引用值”，不是“引用本身”的可变容器
Java 虚拟机栈中每个栈帧保存的局部变量表，存放的是：
- 8 种基本类型的实际值（如 int、boolean）
- 对象的引用值（即指向堆中对象的地址，本质是一个数值）
这个引用值在栈帧生命周期内可以被重新赋值（比如 s = "new"），但这种“重赋值”只是改变栈上那个局部变量所持有的地址，并不改变它原本指向的对象。而所谓“不可变”，真正约束的是对象自身状态不能被修改（如 String、LocalDateTime），而非栈上那个变量能不能换目标。
二、“捕获”行为发生在 Lambda/匿名类，约束来自语义而非栈机制
面试中常提的“被栈捕获的变量必须是 final 或 effectively final”，根源不在虚拟机栈，而在Java 语言规范对闭包语义的定义：
- Lambda 表达式可能在另一个线程执行，若允许捕获可变局部变量，就等于让多个线程共享栈上数据——但栈是线程私有的，无法直接共享
- 为避免歧义，JVM 规定：Lambda 实际捕获的是该局部变量在创建时的快照值（对引用类型就是当时的对象地址）
- 如果允许后续修改该局部变量，就会导致“捕获值”和“原始变量值”不一致，破坏语义一致性
所以编译器强制其为 effectively final，不是因为栈不让改，而是因为“捕获”这个动作要求值稳定。
三、实例变量没这限制，因为它们本就不在栈上
对比来看，Lambda 可以自由访问 this 引用下的实例字段，原因很直接：
- 实例变量存在堆中，属于对象状态，天然可被多线程访问
- 是否可变，取决于字段声明（final？）、对象设计（是否不可变类？）和同步策略，而不是栈的限制
- “this” 被隐式视为 final 局部变量（即 Lambda 捕获的是 this 的值，不是 this 所指对象的内容）
也就是说，你改的是堆里的东西，栈上那个 this 引用值本身从没变过。
四、C# 的 readonly 字段与 Java 的 final 局部变量逻辑相通
类似地，C# 中 readonly 字段只能在声明或构造函数中赋值，也是为了保证对象构建完成后状态稳定；Java 中 final 局部变量只许赋值一次，是为了确保闭包看到的值不会随外部变化而“漂移”。两者都不是虚拟机栈的硬性禁止，而是语言层面对确定性行为的主动约束。
