阅读完需:约 3 分钟
在早期的版本中,本地类,匿名类访问本地变量都需要是final的。
但是1.8版本中,本地类和匿名类,还有lambda表达式访问本地变量已经不用声明为final了,仅仅是不用明确写为final,其实还是final的,这种不明确性可以称之为effectively final,也就是你声明的是一个非final的变量,但是你只要不改变它就可以了。
先来看看官方(Java 8 的规格说明书)是怎么说的,如下:
a final variable can be defined as An entity once that cannot be changed nor derived from later and an effectively final defined as variable or parameter whose value is never changed after it is initialized is effectively final.
就像你看到的,上面这段解释并没有针对关键词“effectively”进行详细的说明——看得云里雾里的,等于没看。
来看下面这段代码:
int limit = 10;
Runnable r = () -> {
limit = 5;
for (int i = 0; i < limit; i++) {
System.out.println(i);
}
};
new Thread(r).start();
编译器会提醒我们“Lambda 表达式中的变量必须是 final 或者 effectively final”,按照编译器的提示,我们把 limit 变量修饰为 final,但这时候,编译器提示了新的错误。

这次的错误就很明确了,final 变量是不能被重新赋值的——众所周知,这正是 final 关键字的作用——于是我们把 limit = 5
这行代码去掉。
final int limit = 10;
Runnable r = () -> {
for (int i = 0; i < limit; i++) {
System.out.println(i);
}
};
new Thread(r).start();
考虑到 limit 在接下来的代码中并未被重新赋值,我们可以将 final 关键字去掉。
int limit = 10;
Runnable r = () -> {
for (int i = 0; i < limit; i++) {
System.out.println(i);
}
};
new Thread(r).start();
代码仍然可以正常编译,正常运行,那么此时的 limit 变量就是“effectively final”的。由于 limit 在接下来的代码中没有被重新赋值,编译器就被欺骗了,想当然地认为 limit 就是一个 final 变量(实际上的最终变量)。
假如 limit 在声明为普通的变量(没有 final 修饰)后又被重新赋值了,那也就不可能成为“effectively final”了。
因此得出的结论是,“effectively final”是一个行为类似于“final”的变量,但没有将其声明为“final”变量,关键就在于编译器是怎么看待的。