Java final 关键字

final 关键字一般会多用于这样的几个地方：

• 变量
  当final变量是基本数据类型以及String类型时，如果在编译期间能知道它的确切值，则编译器会把它当做编译期常量使用。

• 防止被重写
  比如：java.lang.String 类

• 内部类访问外部局部变量
  这个我们经常使用，而且IDE也会提示你。但是你有没有想过Java为什么要设计成这样，这其中的秘密何在？
  比如，我们有这样的代码：

  	// 这个方法没有意义
      public void fun() {
          final int i = 10;
          new Thread(new Runnable() {
              @Override
              public void run() {
                  int c = i + 10;
              }
          }).start();
      }
  

  如果，我们没有给 i 声明 final 修饰符，IDE就会报一个错误（need to be final）。需要声明为 final 是因为，编译器编译的时候其实悄悄对函数做了手脚，偷偷把外部环境方法的局部变量 i，拷贝了一份到匿名内部类里。其实我们的代码经过编译之后变成了这样：

      public void fun() {
          final int i = 10;
          new Thread(new Runnable() {
          	// copy 了一份
              int copyI = i;
              
              @Override
              public void run() {
                  int c = i+10;
              }
          }).start();
      }
  

  所以，这样就知道为啥需要声明为 final 了，因为内部拷贝了一份，而内部使用到了这个变量的值，如果在运行时外部的值改变了，那么内部的值却没有更新，就会出现各种问题，所以就干脆不让它改变。

• 并发
  以前在面试的时候，总是有很多面试官喜欢问：final、finally的区别！这特么就很蛋疼，这两货除了长的像，有啥是一样的。其实他们应该问 final 与 volatile 有啥区别？这个问题就比较阴险了，如果你不往并发上想的话，就会觉得这特么是什么脑残问题！！

  说到这里，我们还是应该从 Java 的内存模型说起。

  大家都知道，计算机在执行程序时，每条指令都是在CPU中执行的，而执行指令过程中，势必涉及到数据的读取和写入。由于程序运行过程中的临时数据是存放在主存（物理内存）当中的，这时就存在一个问题，由于CPU执行速度很快，而从内存读取数据和向内存写入数据的过程跟CPU执行指令的速度比起来要慢的多，因此如果任何时候对数据的操作都要通过和内存的交互来进行，会大大降低指令执行的速度，因此在CPU里面就有了高速缓存。

  也就是，当程序在运行过程中，会将运算需要的数据从主存复制一份到CPU的高速缓存当中，那么CPU进行计算时就可以直接从它的高速缓存读取数据和向其中写入数据，当运算结束之后，再将高速缓存中的数据刷新到主存当中。举个简单的例子，比如下面的这段代码：

  i = i + 1;
  

  当线程执行这个语句时，会先从主存当中读取i的值，然后复制一份到高速缓存当中，然后CPU执行指令对i进行加1操作，然后将数据写入高速缓存，最后将高速缓存中i最新的值刷新到主存当中。

  这个代码在单线程中运行是没有任何问题的，但是在多线程中运行就会有问题了。在多核CPU中，每条线程可能运行于不同的CPU中，因此每个线程运行时有自己的高速缓存（对单核CPU来说，其实也会出现这种问题，只不过是以线程调度的形式来分别执行的，下面以多核CPU为例）。

  可能存在下面一种情况：初始时，两个线程分别读取i的值存入各自所在的CPU的高速缓存当中，然后线程1进行加1操作，然后把i的最新值1写入到内存。此时线程2的高速缓存当中i的值还是0，进行加1操作之后，i的值为1，然后线程2把i的值写入内存。

  最终结果i的值是1，而不是2。这就是著名的缓存一致性问题。通常称这种被多个线程访问的变量为共享变量。

  也就是说，如果一个变量在多个CPU中都存在缓存（一般在多线程编程时才会出现），那么就可能存在缓存不一致的问题。

  为了解决缓存不一致性问题，通常来说有以下2种解决方法：

  • 通过在总线加LOCK#锁的方式
  • 通过缓存一致性协议

  这2种方式都是硬件层面上提供的方式。

  在早期的CPU当中，是通过在总线上加LOCK#锁的形式来解决缓存不一致的问题。因为CPU和其他部件进行通信都是通过总线来进行的，如果对总线加LOCK#锁的话，也就是说阻塞了其他CPU对其他部件访问（如内存），从而使得只能有一个CPU能使用这个变量的内存。比如上面例子中 如果一个线程在执行 i = i +1，如果在执行这段代码的过程中，在总线上发出了LCOK#锁的信号，那么只有等待这段代码完全执行完毕之后，其他CPU才能从变量i所在的内存读取变量，然后进行相应的操作。这样就解决了缓存不一致的问题。

  但是上面的方式会有一个问题，由于在锁住总线期间，其他CPU无法访问内存，导致效率低下。

  所以就出现了缓存一致性协议。最出名的就是Intel 的MESI协议，MESI协议保证了每个缓存中使用的共享变量的副本是一致的。它核心的思想是：当CPU写数据时，如果发现操作的变量是共享变量，即在其他CPU中也存在该变量的副本，会发出信号通知其他CPU将该变量的缓存行置为无效状态，因此当其他CPU需要读取这个变量时，发现自己缓存中缓存该变量的缓存行是无效的，那么它就会从内存重新读取。

  

说完了内存模型，我们还要了解并发中的3个名词：

• 原子性：即一个操作或者多个操作 要么全部执行并且执行的过程不会被任何因素打断，要么就都不执行。
• 可见性：当多个线程访问同一个变量时，一个线程修改了这个变量的值，其他线程能够立即看得到修改的值。
• 有序性：即程序执行的顺序按照代码的先后顺序执行。

这3个名词就不细说了，有兴趣的可以自己查查资料。

最后，我们来说，Java 的内存模型。

在Java虚拟机规范中试图定义一种Java内存模型（Java Memory Model，JMM）来屏蔽各个硬件平台和操作系统的内存访问差异，以实现让Java程序在各种平台下都能达到一致的内存访问效果。那么Java内存模型规定了哪些东西呢，它定义了程序中变量的访问规则，往大一点说是定义了程序执行的次序。注意，为了获得较好的执行性能，Java内存模型并没有限制执行引擎使用处理器的寄存器或者高速缓存来提升指令执行速度，也没有限制编译器对指令进行重排序。也就是说，在java内存模型中，也会存在缓存一致性问题和指令重排序的问题。

Java内存模型规定所有的变量都是存在主存当中（类似于前面说的物理内存），每个线程都有自己的工作内存（类似于前面的高速缓存）。线程对变量的所有操作都必须在工作内存中进行，而不能直接对主存进行操作。并且每个线程不能访问其他线程的工作内存。

了解了这些，我们再来看看 volatile 的作用：
一旦一个共享变量（类的成员变量、类的静态成员变量）被volatile修饰之后，那么就具备了两层语义：

1. 保证了不同线程对这个变量进行操作时的可见性，即一个线程修改了某个变量的值，这新值对其他线程来说是立即可见的。
2. 禁止进行指令重排序。

那么这两句话是什么意思呢？可见性比较好理解，就是一个线程更改了值，另外一个线程需要重新读取这个值。这里又有一个很有趣的问题，看下面的代码：

public volatile int inc = 0;

public void increase() {
	inc++;
}

当这个方法在多线程中运行的时候，会出现问题。我们来细细说到一下：

假如某个时刻变量inc的值为10，

线程1对变量进行自增操作，线程1先读取了变量inc的原始值，然后线程1被阻塞了；

然后线程2对变量进行自增操作，线程2也去读取变量inc的原始值，由于线程1只是对变量inc进行读取操作，而没有对变量进行修改操作，所以不会导致线程2的工作内存中缓存变量inc的缓存行无效，所以线程2会直接去主存读取inc的值，发现inc的值时10，然后进行加1操作，并把11写入工作内存，最后写入主存。

然后线程1接着进行加1操作，由于已经读取了inc的值，注意此时在线程1的工作内存中inc的值仍然为10，所以线程1对inc进行加1操作后inc的值为11，然后将11写入工作内存，最后写入主存。

那么两个线程分别进行了一次自增操作后，inc只增加了1。

这里可能就有人想不通了，线程 1 从阻塞变为运行状态后，应该还需要再次读取 inc 的值才对啊，为啥它没有读取呢？其实还是那个原因，我们写的是Java代码，而程序运行的是指令，我们将 inc++ 这行代码转成指令看看：

0: iconst_1
1: istore_1
2: iinc 1, 1

那么，这3个指令是啥意思呢？我们再将这3个指令转为 Java 代码看看：

public void increase(){
	int tmp = inc; // 0
	tmp = tmp + 1; // 1
	inc = tmp; // 2
}

嗯，现在明白了吧。再 inc++ 这个过程中，由于对 inc 的读取在阻塞前已经完成了，所以后面就不用再次读取了。

再说一个有趣的例子，我们有这样的代码：

//线程1
boolean stop = false;
while(!stop){
    doSomething();
}
 
//线程2
stop = true;

这段代码是很典型的一段代码，很多人在中断线程时可能都会采用这种标记办法。但是事实上，这段代码会完全运行正确么？即一定会将线程中断么？

答案是不一定，也许在大多数时候，这个代码能够把线程中断，但是也有可能会导致无法中断线程（虽然这个可能性很小，但是只要一旦发生这种情况就会造成死循环了）。

也许你会很奇怪，就算是多线程，这段代码也不会出现问题啊，怎么可能会出现死循环，简直是无稽之谈！

实际上，从代码上来看，只要线程2后执行，那么就一定会终止线程。但是，我们需要知道我们写出来的代码不一定就是运行的代码（编译器还会做一些手脚的）。在某些情况下，编译器会直接将上面的代码优化成下面这样：

//线程1
boolean stop = false;
// 这里编译器做了优化
while(true){
    doSomething();
}
 
//线程2
stop = true;

可以看到，由于没有 volatile 关键字，编译器不知道它是多线程程序，所以就直接优化成了死循环。

下面，来到了我们想要说的重点，重排序。啥是重排序呢？一般来说，处理器为了提高程序运行效率，可能会对输入代码进行优化，它不保证程序中各个语句的执行先后顺序同代码中的顺序一致，但是它会保证程序最终执行结果和代码顺序执行的结果是一致的。

一般情况下，这个优化没啥问题，它不会影响单个线程内程序执行的结果，但是多线程呢？下面看一个例子：

//线程1:
context = loadContext();   //语句1
inited = true;             //语句2
 
//线程2:
while(!inited ){
  sleep()
}
doSomethingwithconfig(context);

上面代码中，由于语句1和语句2没有数据依赖性，因此可能会被重排序。假如发生了重排序，在线程1执行过程中先执行语句2，而此是线程2会以为初始化工作已经完成，那么就会跳出while循环，去执行doSomethingwithconfig(context)方法，而此时context并没有被初始化，就会导致程序出错。

如果，我们给 inited 添加 volatile 关键字，那么就不会发生指令重排序，程序也就不会出错。

说完了 volatile 对重排序的影响，下面我们说说 final，它对重排序也有一点的影响。

对于 final 域，编译器和处理器要遵守两个重排序规则：

在构造函数内对一个 final 域的写，与随后把这个构造对象的引用赋值给一个变量，这两个操作之间不能重排序

初次读一个包含 final 域的对象的引用，与随后初次读这个 final 域，这两个操作之间不能重排序

举个例子（摘自《Java并发编程实践》）：

    public class Holder {
        private int n;
        public Holder(int n) { this.n = n; }
        public void assertSanity() {
            if (n != n)
                throw new AssertionError("error");
        }
    }

假设这里有一个线程A执行了下面一段代码：

Holder holder = new Holder(10);

同时有另一个线程B也在执行下面这段代码：

if (holder != null) holder.assertSanity();

那么在某些情况下就会抛出上面的异常，原因就是：
Holder holder = new Holder(10);其实是由三步组成的

1. 给holder分配内存
2. 调用构造函数
3. 将holder指向刚分配的内存

理想中是这个执行顺序，然而事实上这三步并不一定按照这个顺序执行，是为了优化效率而存在的指令重排在作怪，假如一个执行顺序为1 3 2，那么在刚执行完1和3的时候线程切换到B，这时候holder由于指向了内存所以不为空并调用assertSanity函数，该函数中的if语句并不是一步完成：

1. 取左表达式n的值
2. 取右表达式n的值
3. 进行！=表达式运算

那么假设刚执行完第一步的时候B线程挂起并重新回到A线程，A线程继续执行构造函数并将n赋值为10，然后再次跳回B线程，这时候执行第2步，那么就会造成前后取到的n不一样，从而抛出异常。

那么加了final修饰之后会如何呢，JVM做了如下保证：一旦对象引用对其他线程可见，则其final成员也必须正确的赋值了。就是说一旦你得到了引用，final域的值(即n)都是完成了初始化的，因此不会再抛出上面的异常。