java为什么匿名内部类的参数引用时final？
当年我也被这个问题困扰过，背了答案但总觉得哪里不对。后来想通了，其实就一个核心问题：变量没了，内部类还在，怎么办？
先看现象
public void test() {
int count = 0;
new Thread(() -> {
System.out.println(count); // 这行OK
count++; // 这行编译报错
}).start();
}编译器会告诉你：Variable used in lambda expression should be final or effectively final
Java 8之前更狠，必须显式写final int count = 0，否则连读都不让读。Java 8放宽了，只要你”事实上没改过”（effectively final），就不用写final关键字了。但本质没变——不让你改。
为什么？
生命周期不一样，这是根本原因
局部变量count存在栈上，方法test()执行完，栈帧弹出，count就没了，灰飞烟灭。
但那个new Thread()创建的线程对象呢？它在堆上，可能活很久。主线程早就从test()返回了，这个线程还在跑，还想用count。
变量都没了，你让内部类用什么？总不能让它去访问一块已经被回收的内存吧，那不就野指针了。
Java的解决方案：抄一份
Java的做法很朴实——既然原件要销毁，那我复印一份呗。
编译器会把匿名内部类引用的外部变量，复制一份到内部类对象里。反编译看一下就明白了：
// 你写的代码
new Thread(() -> {
System.out.println(count);
}).start();
// 编译器实际生成的（大致）
class Test$1 implements Runnable {
final int val$count; // 复制过来的
Test$1(int count) {
this.val$count = count;
}
public void run() {
System.out.println(val$count);
}
}
new Thread(new Test$1(count)).start();看到没？count被复制到了val$count里。内部类用的根本不是原来那个count，是它自己的副本。
这叫值捕获（capture by value），不是引用捕获。
为什么必须final？
既然是复制，那问题就来了。
假设Java允许你修改，你在内部类里写count++，改的是谁？是内部类自己的副本val$count，还是外面的count？
如果改的是副本，外面的count不变，这不是坑爹吗？你以为改了，其实没改。
如果要同步修改两边……那复杂度就上去了，而且栈上的变量可能已经没了，同步个寂寞。
Java设计者选择了最简单粗暴的方案：干脆不让你改。
用final一锁，变量不可变，复制前后值一样，就不存在”改了到底改的是谁”的问题了。简单、清晰、不容易出bug。
和JavaScript对比一下
JavaScript的闭包是真正的引用捕获：
function test() {
let count = 0;
setTimeout(() => {
count++;
console.log(count); // 输出1
}, 1000);
count = 100;
}JS里面，内部函数真的引用了外面的count，不是复制。你改count，里面看到的也变了。
这是因为JS的变量不在栈上，而是在”词法环境”对象里，这个对象会被闭包持有，不会随着函数返回而销毁。
Java没走这条路。Java的局部变量就是在栈上，设计上不支持这种”延长生命周期”的机制。所以只能复制，复制就必须final。
那我真想改怎么办？
实际开发中确实会遇到这种需求，有几个绕过的办法，各有利弊：
1. 用数组包一层
int[] count = {0};
new Thread(() -> {
count[0]++; // OK，改的是数组内容，不是引用
}).start();数组引用count是final的（不能指向别的数组），但数组里面的内容可以改。
2. 用AtomicInteger
AtomicInteger count = new AtomicInteger(0);
new Thread(() -> {
count.incrementAndGet(); // OK
}).start();这是正经做法，还顺便解决了线程安全问题。
3. 用成员变量
private int count = 0;
public void test() {
new Thread(() -> {
count++; // OK，成员变量不受限制
}).start();
}成员变量在堆上，生命周期跟对象走，不存在”方法返回就没了”的问题。
effectively final是什么意思
Java 8之后，你不用显式写final了，但变量必须”事实上不变”：
int count = 0;
// 这里不能有count = xxx的操作
new Thread(() -> {
System.out.println(count); // OK
}).start();
// 这里也不能有count = xxx的操作只要你从头到尾没给count重新赋值，编译器就认为它是”effectively final”，允许在lambda里用。
这纯粹是语法糖，省得你写一堆final，但本质还是那个本质。
说到底
整个逻辑链就是：
局部变量在栈上 → 方法返回变量就没了 → 内部类可能还活着要用 → 只能复制一份 → 复制了就有两份 → 如果允许改，改的是哪份？ → 有歧义 → 干脆不让改
Java选择了”值捕获+禁止修改”，JS选择了”引用捕获+允许修改”，没有对错，设计哲学不同。
当年想通这个的时候，突然觉得很多”奇怪的规定”都有道理了。语言设计者不是闲着没事折腾你，是真有坑要填。
浙公网安备 33010602011771号