文章内容收拾自博学谷狂野架构师

敞开生长之旅！这是我参加「日新计划 2 月更文应战」的第 14 天，点击检查活动概况

final实现原理

简介

final关键字，实践的意义就一句话，不行改动。什么是不行改动？便是初始化完结之后就不能再做任何的修正，润饰成员变量的时分，成员变量变成一个常数；润饰办法的时分，办法不允许被重写；润饰类的时分，类不允许被承继；润饰参数列表的时分，入参的目标也是不行以改动。这个便是不行变，无论是引证新的目标，重写还是承继，都是改动的办法，而final便是把这个改动的路给堵死

用法

final润饰变量

  • final成员变量标明常量，只能被赋值一次，赋值后值不再改动（final要求地址值不能改动）
  • 当final润饰一个根本数据类型时，标明该根本数据类型的值一旦在初始化后便不能发生改动；
  • 假如final润饰一个引证类型时，则在对其初始化之后便不能再让其指向其他目标了，但该引证所指向的目标的内容是能够发生改动的。本质上是一回事，因为引证的值是一个地址，final要求值，即地址的值不发生改动。
  • final润饰一个成员变量（特点），必需求显示初始化。这儿有两种初始化方式。
    • 一种是在变量声明的时分初始化。
    • 第二种办法是在声明变量的时分不赋初值，可是要在这个变量所在的类的一切的结构函数中对这个变量赋初值。

final润饰办法

运用final办法的原因有两个。

  • 第一个原因是把办法锁定，以防任何承继类修正它的意义，不能被重写；
  • 第二个原因是功率，final办法比非final办法要快，因为在编译的时分现已静态绑定了，不需求在运行时再动态绑定。

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

final润饰类

当用final润饰一个类时，标明这个类不能被承继。

final类中的成员变量能够根据需求设为final，可是要留意final类中的一切成员办法都会被隐式地指定为final办法。

在运用final润饰类的时分，要留意慎重选择，除非这个类真的在今后不会用来承继或许出于安全的考虑，尽量不要将类规划为final类。

final关键字的好处

  • final关键字提高了功能。JVM和Java运用都会缓存final变量。
  • final变量能够安全的在多线程环境下进行共享，而不需求额外的同步开销。
  • 运用final关键字，JVM会对办法、变量及类进行优化。

留意事项

  • final关键字能够用于成员变量、本地变量、办法以及类。
  • final成员变量必须在声明的时分初始化或许在结构器中初始化，不然就会报编译过错。
  • 你不能够对final变量再次赋值。
  • 本地变量必须在声明时赋值。
  • 在匿名类中一切变量都必须是final变量。
  • final办法不能被重写。
  • final类不能被承继。
  • final关键字不同于finally关键字，后者用于异常处理。
  • final关键字容易与finalize()办法搞混，后者是在Object类中定义的办法，是在废物收回之前被JVM调用的办法。
  • 接口中声明的一切变量自身是final的。
  • final和abstract这两个关键字是反相关的，final类就不行能是abstract的。
  • final办法在编译阶段绑定，称为静态绑定(static binding)。
  • 没有在声明时初始化final变量的称为空白final变量(blank final variable)，它们必须在结构器中初始化，或许调用this()初始化。不这么做的话，编译器会报错“final变量(变量名)需求进行初始化”。
  • 将类、办法、变量声明为final能够提高功能，这样JVM就有机会进行估量，然后优化。
  • 按照Java代码惯例，final变量便是常量，而且一般常量名要大写。
  • 对于集合目标声明为final指的是引证不能被更改，可是你能够向其间增加，删去或许改动内容。

原理

内存语义

写内存语义能够确保在目标的引证为恣意线程可见之前，final 域现已被初始化过了。

读内存语义能够确保假如目标的引证不为 null，则阐明 final 域现已被初始化过了。

总之，final 域的内存语义供给了初始化安全确保。

  • 写内存语义：在结构函数内对一个 final 域的写入，与随后将目标引证赋值给引证变量，这两个操作不能重排序。
  • 读内存语义：初度读一个包括 final 域的目标的引证，与随后初度读这个 final 域，这两个操作不能重排序。

写 final 域的重排序规矩

写 final 域的重排序规矩制止把 final 域的写重排序到结构函数之外。这个规矩的实现包括下面 2 个方面：

  • JMM 制止编译器把 final 域的写重排序到结构函数之外。
  • 编译器会在 final 域的写之后，结构函数 return 之前，刺进一个 StoreStore 屏障。这个屏障制止处理器把 final 域的写重排序到结构函数之外。

现在让咱们剖析 writer () 办法。writer () 办法只包括一行代码：finalExample = new FinalExample ()。这行代码包括两个过程：

  1. 结构一个 FinalExample 类型的目标；
  2. 把这个目标的引证赋值给引证变量 obj。

假定线程 B 读目标引证与读目标的成员域之间没有重排序（马上会阐明为什么需求这个假定），下图是一种或许的履行时序：

从菜鸟程序员到高级架构师，竟然是因为这个字final

在上图中，写一般域的操作被编译器重排序到了结构函数之外，读线程 B 过错的读取了一般变量 i 初始化之前的值。而写 final 域的操作，被写 final 域的重排序规矩“限制”在了结构函数之内，读线程 B 正确的读取了 final 变量初始化之后的值。

写 final 域的重排序规矩能够确保：在目标引证为恣意线程可见之前，目标的 final 域现已被正确初始化过了，而一般域不具有这个保障。以上图为例，在读线程 B“看到”目标引证 obj 时，很或许 obj 目标还没有结构完结（对一般域 i 的写操作被重排序到结构函数外，此刻初始值 2 还没有写入一般域 i）。

读 final 域的重排序规矩

读 final 域的重排序规矩如下：

在一个线程中，初度读目标引证与初度读该目标包括的 final 域，JMM 制止处理器重排序这两个操作（留意，这个规矩仅仅针对处理器）。编译器会在读 final 域操作的前面刺进一个 LoadLoad 屏障。

初度读目标引证与初度读该目标包括的 final 域，这两个操作之间存在直接依靠联系。因为编译器恪守直接依靠联系，因而编译器不会重排序这两个操作。大多数处理器也会恪守直接依靠，大多数处理器也不会重排序这两个操作。但有少量处理器允许对存在直接依靠联系的操作做重排序（比方 alpha 处理器），这个规矩便是专门用来针对这种处理器。

reader() 办法包括三个操作：

  1. 初度读引证变量 obj;
  2. 初度读引证变量 obj 指向目标的一般域 j。
  3. 初度读引证变量 obj 指向目标的 final 域 i

现在咱们假定写线程 A 没有发生任何重排序，一起程序在不恪守直接依靠的处理器上履行，下面是一种或许的履行时序

从菜鸟程序员到高级架构师，竟然是因为这个字final

在上图中，读目标的一般域的操作被处理器重排序到读目标引证之前。读一般域时，该域还没有被写线程 A 写入，这是一个过错的读取操作。而读 final 域的重排序规矩会把读目标 final 域的操作“限制”在读目标引证之后，此刻该 final 域现已被 A 线程初始化过了，这是一个正确的读取操作。

读 final 域的重排序规矩能够确保：在读一个目标的 final 域之前，必定会先读包括这个 final 域的目标的引证。在这个示例程序中，假如该引证不为 null，那么引证目标的 final 域必定现已被 A 线程初始化过了。

假如 final 域是引证类型

上面咱们看到的 final 域是根底数据类型，下面让咱们看看假如 final 域是引证类型，将会有什么作用？

请看下列示例代码：

COPYpublic class FinalReferenceExample {
    final int[] intArray;                     //final 是引证类型 
    static FinalReferenceExample obj;
    public FinalReferenceExample () {        // 结构函数 
        intArray = new int[1];              //1
        intArray[0] = 1;                   //2
    }
    public static void writerOne () {          // 写线程 A 履行 
        obj = new FinalReferenceExample ();  //3
    }
    public static void writerTwo () {          // 写线程 B 履行 
        obj.intArray[0] = 2;                 //4
    }
    public static void reader () {              // 读线程 C 履行 
        if (obj != null) {                    //5
            int temp1 = obj.intArray[0];       //6
        }
    }
}

这儿 final 域为一个引证类型，它引证一个 int 型的数组目标。对于引证类型，写 final 域的重排序规矩对编译器和处理器增加了如下束缚：

在结构函数内对一个 final 引证的目标的成员域的写入，与随后在结构函数外把这个被结构目标的引证赋值给一个引证变量，这两个操作之间不能重排序。

对上面的示例程序，咱们假定首要线程 A 履行 writerOne() 办法，履行完后线程 B 履行 writerTwo() 办法，履行完后线程 C 履行 reader () 办法。下面是一种或许的线程履行时序：

从菜鸟程序员到高级架构师，竟然是因为这个字final

在上图中，1 是对 final 域的写入，2 是对这个 final 域引证的目标的成员域的写入，3 是把被结构的目标的引证赋值给某个引证变量。这儿除了前面说到的 1 不能和 3 重排序外，2 和 3 也不能重排序。

JMM 能够确保读线程 C 至少能看到写线程 A 在结构函数中对 final 引证目标的成员域的写入。即 C 至少能看到数组下标 0 的值为 1。而写线程 B 对数组元素的写入，读线程 C 或许看的到，也或许看不到。JMM 不确保线程 B 的写入对读线程 C 可见，因为写线程 B 和读线程 C 之间存在数据竞争，此刻的履行成果不行预知。

假如想要确保读线程 C 看到写线程 B 对数组元素的写入，写线程 B 和读线程 C 之间需求运用同步原语（lock 或 volatile）来确保内存可见性。

为什么 final 引证不能从结构函数内“逸出”

前面咱们说到过，写 final 域的重排序规矩能够确保：在引证变量为恣意线程可见之前，该引证变量指向的目标的 final 域现已在结构函数中被正确初始化过了。其实要得到这个作用，还需求一个确保：在结构函数内部，不能让这个被结构目标的引证为其他线程可见，也便是目标引证不能在结构函数中“逸出”。为了阐明问题，让咱们来看下面示例代码：

COPYpublic class FinalReferenceEscapeExample {
    final int i;
    static FinalReferenceEscapeExample obj;
    public FinalReferenceEscapeExample () {
        i = 1;                              //1 写 final 域 
        obj = this;                          //2 this 引证在此“逸出”
    }
    public static void writer() {
        new FinalReferenceEscapeExample ();
    }    
    public static void reader {
        if (obj != null) {                     //3
            int temp = obj.i;                 //4
        }
    }
}

假定一个线程 A 履行 writer() 办法，另一个线程 B 履行 reader() 办法。这儿的操作 2 使得目标还未完结结构前就为线程 B 可见。即便这儿的操作 2 是结构函数的最后一步，且即便在程序中操作 2 排在操作 1 后边，履行 read() 办法的线程依然或许无法看到 final 域被初始化后的值，因为这儿的操作 1 和操作 2 之间或许被重排序。实践的履行时序或许如下图所示：

从菜鸟程序员到高级架构师，竟然是因为这个字final

从上图咱们能够看出：在结构函数回来前，被结构目标的引证不能为其他线程可见，因为此刻的 final 域或许还没有被初始化。在结构函数回来后，恣意线程都将确保能看到 final 域正确初始化之后的值。

final 语义在处理器中的实现

现在咱们以 x86 处理器为例，阐明 final 语义在处理器中的详细实现。

上面咱们说到，写 final 域的重排序规矩会要求译编器在 final 域的写之后，结构函数 return 之前，刺进一个 StoreStore 障屏。读 final 域的重排序规矩要求编译器在读 final 域的操作前面刺进一个 LoadLoad 屏障。

因为 x86 处理器不会对写 – 写操作做重排序，所以在 x86 处理器中，写 final 域需求的 StoreStore 障屏会被省掉掉。相同，因为 x86 处理器不会对存在直接依靠联系的操作做重排序，所以在 x86 处理器中，读 final 域需求的 LoadLoad 屏障也会被省掉掉。也便是说在 x86 处理器中，final 域的读 / 写不会刺进任何内存屏障！

为什么要增强 final 的语义

在旧的 Java 内存模型中 ，最严峻的一个缺点便是线程或许看到 final 域的值会改动。比方，一个线程当前看到一个整形 final 域的值为 0（还未初始化之前的默认值），过一段时间之后这个线程再去读这个 final 域的值时，却发现值变为了 1（被某个线程初始化之后的值）。最常见的例子便是在旧的 Java 内存模型中，String 的值或许会改动。

为了修补这个缝隙，JSR-133 专家组增强了 final 的语义。通过为 final 域增加写和读重排序规矩，能够为 java 程序员供给初始化安全确保：只要目标是正确结构的（被结构目标的引证在结构函数中没有“逸出”），那么不需求运用同步（指 lock 和 volatile 的运用），就能够确保恣意线程都能看到这个 final 域在结构函数中被初始化之后的值。

final、finally、 finalize差异

  • final能够用来润饰类、办法、变量，分别有不同的意义，final润饰的class代表不行以承继扩展，final的变量是不行以修正的，而final的办法也是不行以重写的（override）。
  • finally则是Java确保要点代码必定要被履行的一种机制。咱们能够运用try-finally或许try-catch-finally来进行类似关闭JDBC衔接、确保unlock锁等动作。
  • finalize是根底类java.lang.Object的一个办法，它的规划目的是确保目标在被废物搜集前完结特定资源的收回。finalize机制现在现已不推荐运用，并且在JDK 9开始被标记为deprecated。

往期干货：

  • 为什么大家都说 SELECT * 功率低？

  • 从阿里规约看Spring事务

  • 【代码级】全链路压测的全体架构规划，以及5种实现方案（流量染色、数据阻隔、接口阻隔、零侵入、服务监控）

  • 最近沉浸Redis网络模型，无法自拔！总算知道Redis为啥这么快了

  • 拆开Netty，我发现了这个8个从来没见过的东西？

  • 学习 Shell准没错

  • 最近迷上了源码，Tomcat源码，看我这篇就够了

  • 为什么这11道JVM面试题这么重要（附答案）

  • 芯片战役50年，Intel为什么干不掉AMD?

  • 翻了ConcurrentHashMap1.7 和1.8的源码，我总结了它们的主要差异。

  • 爱上源码，重学Spring AOP深入

  • 9000字，唠唠架构中的规划模式

  • 号外号外！Ant Design Mobile 5.6.0最新实用指南！

  • 15755字，解锁MySQL功能优化新姿态

本文由传智教育博学谷狂野架构师教研团队发布。

假如本文对您有协助，欢迎关注和点赞；假如您有任何建议也可留言谈论或私信，您的支持是我坚持创造的动力。

转载请注明出处！