Java匿名内部类通过编译器生成副本捕获局部变量，要求变量effectively final，延长其生命周期至内部类实例存活期，但不支持可变共享状态，本质是值拷贝而非真正闭包。
Java 中的匿名内部类确实能访问外部局部变量，但这不是传统意义上的“闭包”，而是一种编译器生成的变量捕获机制。理解它，关键在于看清变量生命周期如何被延长、为什么要求 final 或 effectively final，以及底层怎么实现。
匿名内部类捕获的是变量的“副本”，不是引用本身
Java 不允许匿名内部类直接持有栈上局部变量的引用（因为方法执行完，栈帧就销毁了）。编译器会把用到的局部变量复制一份，作为匿名内部类实例的私有字段存进堆里。比如：
// 原始代码
void method() {
int x = 10;
Runnable r = new Runnable() {
public void run() { System.out.println(x); }
};
r.run(); // 输出 10
}
编译后，匿名类实际类似这样：
class AnonymousRunnable implements Runnable {
private final int captured_x; // 编译器自动添加的字段
AnonymousRunnable(int x) { this.captured_x = x; }
public void run() { System.out.println(this.captured_x); }
}
所以 x 的值被拷贝进堆对象中，生命周期随匿名对象存在——这就“延长”了局部变量的可见性，但不是闭包那种自由变量绑定。
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
立即学习“Java免费学习笔记（深入）”；
必须是 effectively final：避免语义不一致
如果允许修改外部局部变量，就会出现“两个地方改同一个逻辑变量”的错觉。而实际上，内部类持有的只是初始快照。为防止混淆，Java 强制要求这些变量不能被重新赋值：
- 即使没写
final，只要没被二次赋值，就是 effectively final，编译通过 - 一旦在匿名类创建前或后对 x 赋新值（如
x = 20;），编译报错 - 这不是技术限制，而是设计选择：保证“捕获时的值”和“使用时的值”严格一致
与真正闭包的区别：没有可变共享状态
像 JavaScript 或 Scala 的闭包，内部函数可以读写外层变量，形成共享状态。Java 匿名内部类做不到这点：
- 无法从内部类反向修改外部局部变量（连编译都不让）
- 外部方法结束后，原始局部变量早已出栈；内部类只保留不可变副本
- 若真需要通信，得借助堆对象（如 AtomicInteger、自定义容器、外部类字段等）
Lambda 表达式延续了同一机制，但更简洁
Java 8+ 的 lambda 其实复用了这套捕获逻辑：
int y = 5;
Runnable r = () -> System.out.println(y); // 同样要求 y effectively final
区别在于语法糖更轻量，且编译后可能复用已有类（如 Singleton），但变量捕获原理完全一致：值拷贝 + final 约束 + 生命周期延长至内部对象存活期。
