为什匿名内部类在访问局部变量的时候要加finanl
在早期 Java 版本（如 Java 7 及之前）中，局部内部类访问外部局部变量时，必须显式声明为 final。
自己的话说就是局部变量储存在栈中而匿名内部类储存在堆中,外部类执行结束后局部变量按理说是要一起结束进入垃圾回收站中,而这个时候匿名内部类可能还没有执行完成,而当内部类也用到了局部变量的时候这时候就会出错,为保证匿名内部类可以在外部类结束回收变量的时候继续顺利执行,其实是编译器在内部类中隐式的复制了一份数据到内部类中,而为保证两份数据在整个执行过程中的一致性所需要final修饰.
Java 8 的改进：effectively final 规则
Java 8 引入 effectively final 概念，允许变量未被显式声明为 final，但在赋值后未被修改，即可被内部类访问。本质仍是值捕获：编译器仍会复制变量值到内部类实例中。避免冗余语法：只要变量在捕获后不会被修改，是否显式声明 final 不影响闭包的一致性，因此放宽限制。
核心原因：保证闭包的一致性
无论 final 还是 effectively final，核心目的都是 确保内部类捕获的变量值在其生命周期内保持一致。
根本原因：局部变量的「栈内存生命周期」与内部类实例的「堆内存生命周期」不匹配，通过 final/effectively final 确保闭包捕获的是稳定值。
Java 设计权衡：牺牲部分灵活性，换取闭包行为的可预测性，避免因变量修改导致的逻辑漏洞。
延伸思考：其他语言（如 Python、JavaScript）的闭包实现方式不同（基于引用捕获），因此无需此限制，但需处理「变量作用域动态变化」的问题（如经典的「循环中闭包」陷阱）
