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 finalJava 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. 用AtomicIntegerAtomicInteger 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选择了”引用捕获允许修改”没有对错设计哲学不同。当年想通这个的时候突然觉得很多”奇怪的规定”都有道理了。语言设计者不是闲着没事折腾你是真有坑要填。