局部变量必须是final或effectively final，因为编译器通过值拷贝将其“快照”注入内部类字段，确保堆中内部类对象访问的副本与原始栈上变量语义一致，避免因栈帧销毁或变量修改导致逻辑错误。
因为局部变量存在栈上，方法一结束就销毁；而局部内部类对象在堆上，可能长期存活。Java 编译器通过值拷贝把变量“快照”存进内部类，final 或 effectively final 是确保这个快照始终可信的唯一方式。
栈和堆的生命周期根本错位
局部变量属于方法的栈帧，方法返回时栈帧立即弹出，变量内存被回收；但局部内部类实例是普通 Java 对象，分配在堆中，可能被监听器、线程、回调等持有数秒甚至数分钟。JVM 不允许堆中对象直接引用已销毁栈上的地址——这不是语法限制，而是内存安全底线。
编译器实际做的是“值拷贝”，不是“变量共享”
你写的代码看似在访问外部变量，实则编译器悄悄做了三件事：
- 把被访问的局部变量值（或引用）复制一份；
- 作为隐式 final 字段注入内部类（如
val$msg）； - 通过构造器传入并初始化，之后不再变更。
比如 String msg = "ok"; new Thread(() -> System.out.println(msg))，内部类读的不是原始 msg，而是自己字段里那个独立副本。
为什么必须是 final 或 effectively final？
这是为了防止副本“过期”导致逻辑错乱：
- 如果变量后续被修改（如
count++），外部值变了，内部类仍用旧副本，结果不一致且难以排查； - effectively final 意味着变量从初始化起从未被重新赋值，编译器据此确信：拷贝那一刻的值已稳定，副本与原始值语义等价；
- 对基本类型，保证数值不变；对引用类型，保证引用不指向别处（对象内容仍可修改）。
成员变量为什么不需要 final？
因为成员变量属于外部类实例，本身就在堆上，生命周期与外部类对象一致。内部类通过 this$0 隐式引用访问它们，天然不存在栈/堆错位问题，无需拷贝，也无需 final 保障。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
