Java基础篇（五）:final关键字

我会带着你远行 2022-05-16 01:40 190阅读 0赞

转载自：

https://www.cnblogs.com/dolphin0520/p/3736238.html

## 一.final关键字的基本用法 ##

在Java中，final关键字可以用来修饰类、方法和变量（包括成员变量和局部变量）。下面就从这三个方面来了解一下final关键字的基本用法。

1.修饰类

当用final修饰一个类时，表明这个类不能被继承。也就是说，如果一个类你永远不会让他被继承，就可以用final进行修饰。final类中的成员变量可以根据需要设为final，但是要注意final类中的所有成员方法都会被隐式地指定为final方法。

例如：

![70][]

在使用final修饰类的时候，要注意谨慎选择，除非这个类真的在以后不会用来继承或者出于安全的考虑，尽量不要将类设计为final类。

2.修饰方法

下面这段话摘自《Java编程思想》第四版第143页：

“使用final方法的原因有两个。第一个原因是把方法锁定，以防任何继承类修改它的含义；第二个原因是效率。在早期的Java实现版本中，会将final方法转为内嵌调用。但是如果方法过于庞大，可能看不到内嵌调用带来的任何性能提升。在最近的Java版本中，不需要使用final方法进行这些优化了。“

因此，如果只有在想明确禁止 该方法在子类中被覆盖的情况下才将方法设置为final的。

注：类的private方法会隐式地被指定为final方法。

3.修饰变量

修饰变量是final用得最多的地方，也是本文接下来要重点阐述的内容。首先了解一下final变量的基本语法：

对于一个final变量，如果是基本数据类型的变量，则其数值一旦在初始化之后便不能更改；如果是引用类型的变量，则在对其初始化之后便不能再让其指向另一个对象。

举个例子：

![70 1][]

上面的一段代码中，对变量i和obj的重新赋值都报错了。

## 二.深入理解final关键字 ##

在了解了final关键字的基本用法之后，这一节我们来看一下final关键字容易混淆的地方。

1.类的final变量和普通变量有什么区别？

当用final作用于类的成员变量时，成员变量（注意是类的成员变量，局部变量只需要保证在使用之前被初始化赋值即可）必须在定义时或者构造器中进行初始化赋值，而且final变量一旦被初始化赋值之后，就不能再被赋值了。

那么final变量和普通变量到底有何区别呢？下面请看一个例子：

![70 2][]

为什么第一个比较结果为true，而第二个比较结果为fasle。

这里面就是final变量和普通变量的区别了，当final变量是基本数据类型以及String类型时，如果在编译期间能知道它的确切值，则编译器会把它当做编译期常量使用。也就是说在用到该final变量的地方，相当于直接访问的这个常量，不需要在运行时确定。这种和C语言中的宏替换有点像。因此在上面的一段代码中，由于变量b被final修饰，因此会被当做编译器常量，所以在使用到b的地方会直接将变量b 替换为它的  值。而对于变量d的访问却需要在运行时通过链接来进行。想必其中的区别大家应该明白了，不过要注意，只有在编译期间能确切知道final变量值的情况下，编译器才会进行这样的优化，比如下面的这段代码就不会进行优化：

![70 3][]

返回值：false

2.被final修饰的引用变量指向的对象内容可变吗？

在上面提到被final修饰的引用变量一旦初始化赋值之后就不能再指向其他的对象，那么该引用变量指向的对象的内容可变吗？看下面这个例子：

![70 4][]

打印输出：1

3.final和static

很多时候会容易把static和final关键字混淆，static作用于成员变量用来表示只保存一份副本，而final的作用是用来保证变量不可变。看下面这个例子：

![70 5][]

输出结果：

![70 6][]

运行这段代码就会发现，每次打印的两个j值都是一样的，而i的值却是不同的。从这里就可以知道final和static变量的区别了。

4.为什么局部内部类和匿名内部类只能访问局部final变量？

想必这个问题也曾经困扰过很多人，在讨论这个问题之前，先看下面这段代码：

![70 7][]

这段代码会被编译成两个class文件：

![70 8][]

默认情况下，编译器会为匿名内部类和局部内部类起名为Outter1.class。默认情况下，编译器会为匿名内部类和局部内部类起名为Outter$x.class（x为正整数）

上段代码中，如果把变量a和b前面的任一个final去掉，这段代码都编译不过。我们先考虑这样一个问题：

当test方法执行完毕之后，变量a的生命周期就结束了，而此时Thread对象的生命周期很可能还没有结束，那么在Thread的run方法中继续访问变量a就变成不可能了，但是又要实现这样的效果，怎么办呢？Java采用了 复制  的手段来解决这个问题。将这段代码的字节码反编译可以得到下面的内容：

![021939271846598.jpg][]

我们看到在run方法中有一条指令：

bipush 10

这条指令表示将操作数10压栈，表示使用的是一个本地局部变量。这个过程是在编译期间由编译器默认进行，如果这个变量的值在编译期间可以确定，则编译器默认会在匿名内部类（局部内部类）的常量池中添加一个内容相等的字面量或直接将相应的字节码嵌入到执行字节码中。这样一来，匿名内部类使用的变量是另一个局部变量，只不过值和方法中局部变量的值相等，因此和方法中的局部变量完全独立开。

下面再看一个例子：

public class Test {
        public static void main(String[] args){
            
        }
        
        public void test(final int b){
            new Thread(){
                public void run(){
                    System.out.println(b);
                };
            }.start();
        }
        
    }

反编译得到：

![021950384493440.jpg][]

我们看到匿名内部类Test$1的构造器含有两个参数，一个是指向外部类对象的引用，一个是int型变量，很显然，这里是将变量test方法中的形参a以参数的形式传进来对匿名内部类中的拷贝（变量a的拷贝）进行赋值初始化。

也就说如果局部变量的值在编译期间就可以确定，则直接在匿名内部里面创建一个拷贝。如果局部变量的值无法在编译期间确定，则通过构造器传参的方式来对拷贝进行初始化赋值。

从上面可以看出，在run方法中访问的变量a根本就不是test方法中的局部变量a。这样一来就解决了前面所说的 生命周期不一致的问题。但是新的问题又来了，既然在run方法中访问的变量a和test方法中的变量a不是同一个变量，当在run方法中改变变量a的值的话，会出现什么情况？

对，会造成数据不一致性，这样就达不到原本的意图和要求。为了解决这个问题，java编译器就限定必须将变量a限制为final变量，不允许对变量a进行更改（对于引用类型的变量，是不允许指向新的对象），这样数据不一致性的问题就得以解决了。

到这里，想必大家应该清楚为何 方法中的局部变量和形参都必须用final进行限定了。

[70]: /images/20220516/ea21b5c84cb546b18834a5a67d97637e.png
[70 1]: /images/20220516/e685adcd0a1e44bda460a0e4d1c3b770.png
[70 2]: /images/20220516/25695b4c52a0410e8c5e4288f87b77f0.png
[70 3]: /images/20220516/3c942fe49b6f4ff993b1133f000cb6e1.png
[70 4]: /images/20220516/d6d0e53a2f0c47c7af086f84e3ac4966.png
[70 5]: /images/20220516/0230b94ffa6e4fcc871750117ccb2c53.png
[70 6]: /images/20220516/e6eec2c4fb784a9180cde05e30ec3e58.png
[70 7]: /images/20220516/755ca2b3d4524fb6933db89e0e5fd3ef.png
[70 8]: /images/20220516/fe422c13556e414a8a499183506c2df9.png
[021939271846598.jpg]: /images/20220516/b14c61dca8904cd0b2af655a1a96c0cb.png
[021950384493440.jpg]: /images/20220516/39bcb663d6b7491da7cf9115a8240b2a.png