java-final关键字

由于语境（应用环境）不同， final 关键字的含义可能会稍微产生一些差异。但它最一般的意思就是声明
“这个东西不能改变”。之所以要禁止改变，可能是考虑到两方面的因素：设计或效率。由于这两个原因颇
有些区别，所以也许会造成 final 关键字的误用。

final可以修饰变量，方法和类，用于表示所修饰的内容一旦赋值之后就不会再被改变，比如String类就是一个final类型的类。

final能够修饰变量，方法和类，也就是final使用范围基本涵盖了java每个地方

　在Java中，final关键字可以用来修饰类、方法和变量（包括成员变量和局部变量）
　final会告诉编译器，这个数据是不会修改的，那么编译器就可能会在编译时期就对该数据进行替换甚至执行计算，这样可以对我们的程序起到一点优化

　修饰类
　
　当一个类被final修饰时，表名该类是不能被子类继承的。子类继承往往可以重写父类的方法和改变父类属性，会带来一定的安全隐患，因此，当一个类不希望被继承时就可以使用final修饰

　表明这个类不能被继承,final类中的所有成员方法都会被隐式地指定为final方法
　如果说整个类都是 final（在它的定义前冠以 final 关键字），就表明自己不希望从这个类继承，或者不允许其他任何人采取这种操作。换言之，出于这样或那样的原因，我们的类肯定不需要进行任何改变；或者出于安全方面的理由，我们不希望进行子类化（子类处理）。
除此以外，我们或许还考虑到执行效率的问题，并想确保涉及这个类各对象的所有行动都要尽可能地有效。如下所示：

//: Jurassic.java
// Making an entire class final
class SmallBrain {}
final class Dinosaur {
int i = 7;
int j = 1;
SmallBrain x = new SmallBrain();
void f() {}
}
//! class Further extends Dinosaur {}
// error: Cannot extend final class 'Dinosaur'
public class Jurassic {
public static void main(String[] args) {
Dinosaur n = new Dinosaur();
n.f();
n.i = 40;
n.j++;
}
} ///:~

注意数据成员既可以是 final，也可以不是，取决于我们具体选择。应用于 final 的规则同样适用于数据成
员，无论类是否被定义成 final。将类定义成 final 后，结果只是禁止进行继承—— 没有更多的限制。然
而，由于它禁止了继承，所以一个 final 类中的所有方法都默认为 final。因为此时再也无法覆盖它们。所
以与我们将一个方法明确声明为 final 一样，编译器此时有相同的效率选择。
可为 final 类内的一个方法添加 final 指示符，但这样做没有任何意义。

不变类

不变类的意思是创建该类的实例后，该实例的实例变量是不可改变的。满足以下条件则可以成为不可变类：

使用private和final修饰符来修饰该类的成员变量

提供带参的构造器用于初始化类的成员变量；

仅为该类的成员变量提供getter方法，不提供setter方法，因为普通方法无法修改fina修饰的成员变量；

如果有必要就重写Object类 的hashCode()和equals()方法，应该保证用equals()判断相同的两个对象其Hashcode值也是相等的。

JDK中提供的八个包装类和String类都是不可变类，我们来看看String的实现。

修饰方法

重写？

当父类的方法被final修饰的时候，子类不能重写父类的该方法，比如在Object中，getClass()方法就是final的，我们就不能重写该方法，但是hashCode()方法就不是被final所修饰的，我们就可以重写hashCode()方法。
1. 父类的final方法是不能够被子类重写的
2. final方法是可以被重载的

把方法锁定，以防任何继承类修改它的含义；

在早期的Java实现版本中，会将final方法转为内嵌调用。但是如果方法过于庞大，可能看不到内嵌调用带来的任何性能提升。在最近的Java版本中，不需要使用final方法进行这些优化了。 如果只有在想明确禁止 该方法在子类中被覆盖的情况下才将方法设置为final的。

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

之所以要使用 final 方法，可能是出于对两方面理由的考虑。第一个是为方法“上锁”，防止任何继承类改
变它的本来含义。设计程序时，若希望一个方法的行为在继承期间保持不变，而且不可被覆盖或改写，就可以采取这种做法。

采用 final 方法的第二个理由是程序执行的效率。将一个方法设成 final 后，编译器就可以把对那个方法的
所有调用都置入“嵌入”调用里。只要编译器发现一个 final 方法调用，就会（根据它自己的判断）忽略为
执行方法调用机制而采取的常规代码插入方法（将自变量压入堆栈；跳至方法代码并执行它；跳回来；清除堆栈自变量；最后对返回值进行处理）。相反，它会用方法主体内实际代码的一个副本来替换方法调用。这样做可避免方法调用时的系统开销。当然，若方法体积太大，那么程序也会变得雍肿，可能受到到不到嵌入代码所带来的任何性能提升。因为任何提升都被花在方法内部的时间抵消了。

Java 编译器能自动侦测这些情况，并颇为“明智”地决定是否嵌入一个 final 方法。然而，最好还是不要完全相信编译器能正确地作出所有判断。通常，只有在方法的代码量非常少，或者想明确禁止方法被覆盖的时候，才应考虑将一个方法设为final。

类内所有 private 方法都自动成为 final。由于我们不能访问一个 private 方法，所以它绝对不会被其他方
法覆盖（若强行这样做，编译器会给出错误提示）。可为一个 private 方法添加 final 指示符，但却不能为那个方法提供任何额外的含义。

修饰变量

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

修饰成员变量

通常每个类中的成员变量可以分为类变量（static修饰的变量）以及实例变量。针对这两种类型的变量赋初值的时机是不同的，类变量可以在声明变量的时候直接赋初值或者在静态代码块中给类变量赋初值。而实例变量可以在声明变量的时候给实例变量赋初值，在非静态初始化块中以及构造器中赋初值。

类变量：必须要在静态初始化块中指定初始值或者声明该类变量时指定初始值，而且只能在这两个地方之一进行指定；

实例变量：必要要在非静态初始化块，声明该实例变量或者在构造器中指定初始值，而且只能在这三个地方进行指定。

类变量有两个时机赋初值，而实例变量则可以有三个时机赋初值。当final变量未初始化时系统不会进行隐式初始化，会出现报错。这样说起来还是比较抽象，下面用具体的代码来演示

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

当final变量是基本数据类型以及String类型时，如果在编译期间能知道它的确切值，则编译器会把它当做编译期常量使用。也就是说在用到该final变量的地方，相当于直接访问的这个常量，不需要在运行时确定
。这种和C语言中的宏替换有点像。由于变量b被final修饰，因此会被当做编译器常量，所以在使用到b的地方会直接将变量b 替换为它的 值。
只有在编译期间能确切知道final变量值的情况下，编译器才会进行这样的优化

匿名内部类中使用的外部局部变量只能是final变量

final 自变量

final局部变量由程序员进行显式初始化，如果final局部变量已经进行了初始化则后面就不能再次进行更改，如果final变量未进行初始化，可以进行赋值，当且仅有一次赋值，一旦赋值之后再次赋值就会出错

final基本数据类型 VS final引用数据类型

通过上面的例子我们已经看出来，如果final修饰的是一个基本数据类型的数据，一旦赋值后就不能再次更改，那么，如果final是引用数据类型了？这个引用的对象能够改变吗？我们同样来看一段代码。

当我们对final修饰的引用数据类型变量person的属性改成22，是可以成功操作的。通过这个实验我们就可以看出来当final修饰基本数据类型变量时，不能对基本数据类型变量重新赋值，因此基本数据类型变量不能被改变。

而对于引用类型变量而言，它仅仅保存的是一个引用，final只保证这个引用类型变量所引用的地址不会发生改变，即一直引用这个对象，但这个对象属性是可以改变的。

Java 1.1 允许我们将自变量设成 final 属性，方法是在自变量列表中对它们进行适当的声明。这意味着在一个方法的内部，我们不能改变自变量句柄指向的东西。如下所示

//: FinalArguments.java
// Using "final" with method arguments
class Gizmo {
public void spin() {}
}
public class FinalArguments {
void with(final Gizmo g) {
//! g = new Gizmo(); // Illegal -- g is final
g.spin();
}
void without(Gizmo g) {
g = new Gizmo(); // OK -- g not final
g.spin();
}
// void f(final int i) { i++; } // Can't change
// You can only read from a final primitive:
int g(final int i) { return i + 1; }
public static void main(String[] args) {
FinalArguments bf = new FinalArguments();
bf.without(null);
bf.with(null);
}
} ///:

注意此时仍然能为 final 自变量分配一个 null（空）句柄，同时编译器不会捕获它。这与我们对非 final 自
变量采取的操作是一样的。方法 f()和 g()向我们展示出基本类型的自变量为 final 时会发生什么情况：我们只能读取自变量，不可改变它

宏变量

利用final变量的不可更改性，在满足一下三个条件时，该变量就会成为一个“宏变量”，即是一个常量。

使用final修饰符修饰；

在定义该final变量时就指定了初始值；

该初始值在编译时就能够唯一指定。

注意：当程序中其他地方使用该宏变量的地方，编译器会直接替换成该变量的值

final数据

//: FinalArguments.java
// Using "final" with method arguments
class Gizmo {
public void spin() {}
}
public class FinalArguments {
void with(final Gizmo g) {
//! g = new Gizmo(); // Illegal -- g is final
g.spin();
}
void without(Gizmo g) {
g = new Gizmo(); // OK -- g not final
g.spin();
}
// void f(final int i) { i++; } // Can't change
// You can only read from a final primitive:
int g(final int i) { return i + 1; }
public static void main(String[] args) {
FinalArguments bf = new FinalArguments();
bf.without(null);
bf.with(null);
}
} ///:~

许多程序设计语言都有自己的办法告诉编译器某个数据是“常数”。常数主要应用于下述两个方面：
(1) 编译期常数，它永远不会改变
(2) 在运行期初始化的一个值，我们不希望它发生变化
对于编译期的常数，编译器（程序）可将常数值“封装”到需要的计算过程里。也就是说，计算可在编译期
间提前执行，从而节省运行时的一些开销。在 Java 中，这些形式的常数必须属于基本数据类型
（ Primitives），而且要用 final 关键字进行表达。在对这样的一个常数进行定义的时候，必须给出一个
值。
无论 static 还是 final 字段，都只能存储一个数据，而且不得改变。
若随同对象句柄使用 final，而不是基本数据类型，它的含义就稍微让人有点儿迷糊了。对于基本数据类
型， final 会将值变成一个常数；但对于对象句柄， final 会将句柄变成一个常数。进行声明时，必须将句柄
初始化到一个具体的对象。而且永远不能将句柄变成指向另一个对象。然而，对象本身是可以修改的。 Java
对此未提供任何手段，可将一个对象直接变成一个常数（但是，我们可自己编写一个类，使其中的对象具有“常数”效果）。这一限制也适用于数组，它也属于对象。

//: FinalData.java
// The effect of final on fields
class Value {
    int i = 1;
}

public class FinalData {
    // Can be compile-time constants
    final int i1 = 9;

    static final int I2 = 99;
    // Typical public constant:

    public static final int I3 = 39;
    // Cannot be compile-time constants:

    final int i4 = (int) (Math.random() * 20);

    static final int i5 = (int) (Math.random() * 20);

    Value v1 = new Value();

    final Value v2 = new Value();

    static final Value v3 = new Value();

    //! final Value v4; // Pre-Java 1.1 Error:
    // no initializer
    // Arrays:
    final int[] a = {1, 2, 3, 4, 5, 6};

    public void print(String id) {
        System.out.println(
                id + ": " + "i4 = " + i4 +
                        ", i5 = " + i5);
    }

    public static void main(String[] args) {
        FinalData fd1 = new FinalData();
//! fd1.i1++; // Error: can't change value
        fd1.v2.i++; // Object isn't constant!
        fd1.v1 = new Value(); // OK -- not final
        for (int i = 0; i < fd1.a.length; i++)
            fd1.a[i]++; // Object isn't constant!
//! fd1.v2 = new Value(); // Error: Can't
//! fd1.v3 = new Value(); // change handle
//! fd1.a = new int[3];
        fd1.print("fd1");
        System.out.println("Creating new FinalData");
        FinalData fd2 = new FinalData();
        fd1.print("fd1");
        fd2.print("fd2");
    }
} ///:~

由于 i1 和 I2 都是具有 final 属性的基本数据类型，并含有编译期的值，所以它们除了能作为编译期的常数
使用外，在任何导入方式中也不会出现任何不同。 I3 是我们体验此类常数定义时更典型的一种方式： public
表示它们可在包外使用； Static 强调它们只有一个；而 final 表明它是一个常数。注意对于含有固定初始化
值（即编译期常数）的 fianl static 基本数据类型，它们的名字根据规则要全部采用大写。也要注意i5 在
编译期间是未知的，所以它没有大写。
不能由于某样东西的属性是 final，就认定它的值能在编译时期知道。 i4 和 i5 向大家证明了这一点。它们在
运行期间使用随机生成的数字。例子的这一部分也向大家揭示出将final 值设为 static 和非 static 之间的
差异。只有当值在运行期间初始化的前提下，这种差异才会揭示出来。因为编译期间的值被编译器认为是相
同的。这种差异可从输出结果中看出：
fd1: i4 = 15, i5 = 9
Creating new FinalData
fd1: i4 = 15, i5 = 9
fd2: i4 = 10, i5 = 9
注意对于 fd1 和 fd2 来说， i4 的值是唯一的，但 i5 的值不会由于创建了另一个 FinalData 对象而发生改
变。那是因为它的属性是 static，而且在载入时初始化，而非每创建一个对象时初始化。
从 v1 到 v4 的变量向我们揭示出 final 句柄的含义。正如大家在 main()中看到的那样，并不能认为由于 v2
属于 final，所以就不能再改变它的值。然而，我们确实不能再将 v2 绑定到一个新对象，因为它的属性是
final。这便是 final 对于一个句柄的确切含义。我们会发现同样的含义亦适用于数组，后者只不过是另一种
类型的句柄而已。将句柄变成 final 看起来似乎不如将基本数据类型变成 final 那么有用。

空白 final

Java 1.1 允许我们创建“空白 final”，它们属于一些特殊的字段。尽管被声明成 final，但却未得到一个
初始值。无论在哪种情况下，空白 final 都必须在实际使用前得到正确的初始化。而且编译器会主动保证这一规定得以贯彻。然而，对于 final 关键字的各种应用，空白 final 具有最大的灵活性。举个例子来说，位于类内部的一个 final 字段现在对每个对象都可以有所不同，同时依然保持其“不变”的本质。下面列出一
现在强行要求我们对 final 进行赋值处理—— 要么在定义字段时使用一个表达 式，要么在每个构建器中。这样就可以确保 final 字段在使用前获得正确的初始化。

class Poppet {
}

class BlankFinal {
    final int i = 0; // Initialized final
    final int j; // Blank final
    final Poppet p; // Blank final handle

    // Blank finals MUST be initialized // in the constructor:
    BlankFinal() {
        j = 1; // Initialize blank final
        p = new Poppet();
    }

    BlankFinal(int x) {
        j = x; // Initialize blank final
        p = new Poppet();
    }

    public static void main(String[] args) {
        BlankFinal bf = new BlankFinal();
    }
} ///:~

f i n a l 的注意事项
设计一个类时，往往需要考虑是否将一个方法设为 final。可能会觉得使用自己的类时执行效率非常重要，没有人想覆盖自己的方法。这种想法在某些时候是正确的。

但要慎重作出自己的假定。通常，我们很难预测一个类以后会以什么样的形式再生或重复利用。常规用途的类尤其如此。若将一个方法定义成 final，就可能杜绝了在其他程序员的项目中对自己的类进行继承的途径，因为我们根本没有想到它会象那样使用。

标准 Java 库是阐述这一观点的最好例子。其中特别常用的一个类是 Vector。如果我们考虑代码的执行效
率，就会发现只有不把任何方法设为 final，才能使其发挥更大的作用。我们很容易就会想到自己应继承和覆盖如此有用的一个类，但它的设计者却否定了我们的想法。但我们至少可以用两个理由来反驳他们。
首先， Stack（堆栈）是从 Vector 继承来的，亦即 Stack“是”一个 Vector，这种说法是不确切的

。其次，对于 Vector 许多重要的方法，如 addElement()以及 elementAt()等，它们都变成了 synchronized（同步的）。正如在第 14 章要讲到的那样，这会造成显著的性能开销，可能会把 final 提供的性能改善抵销得一干二净。因此，程序员不得不猜测到底应该在哪里进行优化。在标准库里居然采用了如此笨拙的设计，真不敢想象会在程序员里引发什么样的情绪。
另一个值得注意的是 Hashtable（散列表），它是另一个重要的标准类。该类没有采用任何final 方法。正
如我们在本书其他地方提到的那样，显然一些类的设计人员与其他设计人员有着全然不同的素质（注意比较Hashtable 极短的方法名与 Vecor 的方法名）。对类库的用户来说，这显然是不应该如此轻易就能看出的。一个产品的设计变得不一致后，会加大用户的工作量。这也从另一个侧面强调了代码设计与检查时需要很强的责任心

多线程中的final
在java内存模型中我们知道java内存模型为了能让处理器和编译器底层发挥他们的最大优势，对底层的约束就很少，也就是说针对底层来说java内存模型就是一弱内存数据模型。
4.1 final域重排序规则
4.1.1 final域为基本类型

public class FinalDemo {
   private int a;  //普通域
   private final int b; //final域
   private static FinalDemo finalDemo;

   public FinalDemo() {
       a = 1; // 1. 写普通域
       b = 2; // 2. 写final域
   }

   public static void writer() {
       finalDemo = new FinalDemo();
   }

   public static void reader() {
       FinalDemo demo = finalDemo; // 3.读对象引用
       int a = demo.a;    //4.读普通域
       int b = demo.b;    //5.读final域
   }
}

假设线程A在执行writer()方法，线程B执行reader()方法。

写final域重排序规则
写final域的重排序规则禁止对final域的写重排序到构造函数之外，这个规则的实现主要包含了两个方面：
JMM禁止编译器把final域的写重排序到构造函数之外；
编译器会在final域写之后，构造函数return之前，插入一个storestore屏障（关于内存屏障可以看这篇文章）。这个屏障可以禁止处理器把final域的写重排序到构造函数之外。

我们再来分析writer方法，虽然只有一行代码，但实际上做了两件事情：
构造了一个FinalDemo对象；
把这个对象赋值给成员变量finalDemo。

由于a,b之间没有数据依赖性，普通域（普通变量）a可能会被重排序到构造函数之外，线程B就有可能读到的是普通变量a初始化之前的值（零值），这样就可能出现错误。而final域变量b，根据重排序规则，会禁止final修饰的变量b重排序到构造函数之外，从而b能够正确赋值，线程B就能够读到final变量初始化后的值。

因此，写final域的重排序规则可以确保：在对象引用为任意线程可见之前，对象的final域已经被正确初始化过了，而普通域就不具有这个保障。比如在上例，线程B有可能就是一个未正确初始化的对象finalDemo。

读final域重排序规则
读final域重排序规则为：在一个线程中，初次读对象引用和初次读该对象包含的final域，JMM会禁止这两个操作的重排序。（注意，这个规则仅仅是针对处理器），处理器会在读final域操作的前面插入一个LoadLoad屏障。

实际上，读对象的引用和读该对象的final域存在间接依赖性，一般处理器不会重排序这两个操作。但是有一些处理器会重排序，因此，这条禁止重排序规则就是针对这些处理器而设定的。

read()方法主要包含了三个操作：
初次读引用变量finalDemo;
初次读引用变量finalDemo的普通域a;
初次读引用变量finalDemo的final与b;

读对象的普通域被重排序到了读对象引用的前面就会出现线程B还未读到对象引用就在读取该对象的普通域变量，这显然是错误的操作。而final域的读操作就“限定”了在读final域变量前已经读到了该对象的引用，从而就可以避免这种情况。

读final域的重排序规则可以确保：在读一个对象的final域之前，一定会先读这个包含这个final域的对象的引用。

final域为引用类型

我们已经知道了final域是基本数据类型的时候重排序规则是怎么的了？如果是引用数据类型了？我们接着继续来探讨。

对final修饰的对象的成员域写操作
针对引用数据类型，final域写针对编译器和处理器重排序增加了这样的约束：在构造函数内对一个final修饰的对象的成员域的写入，与随后在构造函数之外把这个被构造的对象的引用赋给一个引用变量，这两个操作是不能被重排序的。

注意这里的是“增加”也就说前面对final基本数据类型的重排序规则在这里还是使用。这句话是比较拗口的，下面结合实例来看。
针对上面的实例程序，线程线程A执行wirterOne方法，执行完后线程B执行writerTwo方法，然后线程C执行reader方法。下图就以这种执行时序出现的一种情况来讨论（耐心看完才有收获）。

由于对final域的写禁止重排序到构造方法外，因此1和3不能被重排序。由于一个final域的引用对象的成员域写入不能与随后将这个被构造出来的对象赋给引用变量重排序，因此2和3不能重排序。

对final修饰的对象的成员域读操作

JMM可以确保线程C至少能看到写线程A对final引用的对象的成员域的写入，即能看下arrays[0] = 1，而写线程B对数组元素的写入可能看到可能看不到。JMM不保证线程B的写入对线程C可见，线程B和线程C之间存在数据竞争，此时的结果是不可预知的。如果可见的，可使用锁或者volatile。

关于final重排序的总结
按照final修饰的数据类型分类：
基本数据类型:

final域写：禁止final域写与构造方法重排序，即禁止final域写重排序到构造方法之外，从而保证该对象对所有线程可见时，该对象的final域全部已经初始化过。

final域读：禁止初次读对象的引用与读该对象包含的final域的重排序。

引用数据类型：
额外增加约束：禁止在构造函数对一个final修饰的对象的成员域的写入与随后将这个被构造的对象的引用赋值给引用变量 重排序

final的实现原理

上面我们提到过，写final域会要求编译器在final域写之后，构造函数返回前插入一个StoreStore屏障。读final域的重排序规则会要求编译器在读final域的操作前插入一个LoadLoad屏障。

很有意思的是，如果以X86处理为例，X86不会对写-写重排序，所以StoreStore屏障可以省略。由于不会对有间接依赖性的操作重排序，所以在X86处理器中，读final域需要的LoadLoad屏障也会被省略掉。也就是说，以X86为例的话，对final域的读/写的内存屏障都会被省略！具体是否插入还是得看是什么处理器。

为什么final引用不能从构造函数中“溢出”

这里还有一个比较有意思的问题：上面对final域写重排序规则可以确保我们在使用一个对象引用的时候该对象的final域已经在构造函数被初始化过了。

但是这里其实是有一个前提条件的，也就是：在构造函数，不能让这个被构造的对象被其他线程可见，也就是说该对象引用不能在构造函数中“逸出”。以下面的例子来说：

public class FinalReferenceEscapeDemo {
   private final int a;
   private FinalReferenceEscapeDemo referenceDemo;

   public FinalReferenceEscapeDemo() {
       a = 1;  //1
       referenceDemo = this; //2
   }

   public void writer() {
       new FinalReferenceEscapeDemo();
   }

   public void reader() {
       if (referenceDemo != null) {  //3
           int temp = referenceDemo.a; //4
       }
   }
}

假设一个线程A执行writer方法另一个线程执行reader方法。因为构造函数中操作1和2之间没有数据依赖性，1和2可以重排序，先执行了2，这个时候引用对象referenceDemo是个没有完全初始化的对象，而当线程B去读取该对象时就会出错。

尽管依然满足了final域写重排序规则：在引用对象对所有线程可见时，其final域已经完全初始化成功。但是，引用对象“this”逸出，该代码依然存在线程安全的问题。