Java 多线程可见性

在现代操作系统上编写并发程序时，除了要注意线程安全性(多个线程互斥访问临界资源)以外，还要注意多线程对共享变量的可见性，而后者往往容易被人忽略。

可见性是指当一个线程修改了共享变量的值，其它线程能够适时得知这个修改。在单线程环境中，如果在程序前面修改了某个变量的值，后面的程序一定会读取到那个变量的新值。这看起来很自然，然而当变量的写操作和读操作在不同的线程中时，情况却并非如此。

来看看下面的例子吧：

public class NoVisibility {
    private static boolean ready; 
    private static int number;
    
    private static class ReaderThread extends Thread {
        public void run() {
            while(!ready) {
                Thread.yield();
            }
            System.out.println(number);
        }
    }
    
    public static void main(String[] args) {
        new ReaderThread().start(); 
        number = 42;
        ready = true;
    }
}

上面的代码中，主线程和读线程都访问共享变量 ready 和 number。程序看起来会输出 42，但事实上很可能会输出 0，或者根本无法终止。这是因为上面的程序缺少线程间变量可见性的保证，所以在主线程中写入的变量值，可能无法被读线程感知到。虽然在 主线程 中是先修改 number 变量，再修改 ready 变量，但对于 读线程 来说，ready 变量的修改有可能被重排序到number 变量修改之前。

为什么会出现线程可见性问题？

Java 语言规范要求 JVM 只在单个线程内部维护一种类似串行的语义，即只要程序的最终结果与严格串行环境中执行的结果相同即可。所以在单线程环境中，我们无法察觉到重排序，因为程序重排序后的执行结果与严格按顺序执行的结果相同。但是在编写并发程序时，我们一定要注意重排序对多线程执行结果的影响。

事实上，很多主流程序语言(如C/C++)都存在多线程可见性的问题，这些语言是借助物理硬件和操作系统的内存模型来处理多线程可见性问题的，因此不同平台上内存模型的差异，会影响到程序的执行结果。Java 虚拟机规范定义了自己的内存模型 JMM(Java Memory Model) 来屏蔽掉不同硬件和操作系统的内存模型差异，以实现让 Java 程序在各种平台下都能达到一致的内存访问结果。所以对于 Java 程序员，无需了解底层硬件和操作系统内存模型的知识，只要关注Java 自己的内存模型，就能够解决 Java 语言中的内存可见性问题了。

那如何解决 Java 中多线程共享变量的可见性问题呢？

即当一个多线程共享变量被某个线程修改后，如何让这个修改被需要读取这个变量的其他线程感知到呢？

JMM 定义了 Happens-Before 原则。只要我们理解了Happens-Before 原则，无需了解 JVM 底层的内存操作，就可以解决在并发编程中遇到的变量可见性问题。对于两个操作 A 和 B，这两个操作可以在不同的线程中执行。如果 A Happens-Before B，那么可以保证，当 A 操作执行完后，A 操作的执行结果对 B 操作是可见的。

Happens-Before 的规则包括：

1，程序顺序规则

按照程序代码的书写顺序，如果多个操作之间有先后依赖关系，则不允许对这些操作进行重排序。

2，锁定规则

class HappensBeforeLock {
    private int value = 0;
    
    public synchronized void setValue(int value) {
        this.value = value;
    }
    
    public synchronized int getValue() {
        return value;
    }
}

setValue 和 getValue 两个方法共享同一个监视器锁。假设 setValue 方法在线程 A 中执行，getValue 方法在线程B 中执行。setValue 方法会先对value 变量赋值，然后释放锁。getValue 方法会先获取到同一个锁后，再读取 value 的值。所以根据锁定原则，线程 A 中对 value 变量的修改，可以被线程 B 感知到。在锁被释放时，A 线程会把释放锁之前所有的操作结果同步到主内存中，而在获取锁时，B 线程会使自己 CPU 的缓存失效，重新从主内存中读取变量的值。这样，A 线程中的操作结果就会被 B 线程感知到了。

3，volatile 变量规则

volatile 变量可以保证可见性，禁止对变量的操作进行重排序

4，线程启动规则

调用 start() 方法时，会将 start() 方法之前所有操作的结果同步到主内存中，新线程创建好后，需要从主内存获取数据。这样在 start() 方法调用之前的所有操作结果对于新创建的线程都是可见的。

5， 线程结束规则

假设两个线程A、B。在线程 B 中调用 a.join()方法。则线程 B 会被挂起，等待A 线程运行结束才能恢复执行。当 a.join() 成功返回时，B 线程就知道 A 线程已经结束了。在 A 线程中对共享变量的修改，对 B 线程都是可见的。当一个线程结束时，会把自己所有操作的结果都同步到主内存。而任何其它线程当发现这个线程已经执行结束了，就会从主内存中重新刷新最新的变量值。 所以结束的线程 A 对共享变量的修改，对于其它检测了A 线程是否结束的线程是可见的。（Thread.isAlive() 方法可以检测到一个线程是否结束）

6， 中断规则

假设两个线程 A 和 B，A 先做了一些操作，然后调用 B 线程的 interrupt() 方法。当 B 线程感知到自己的中断标识被设置时(通过抛出 InterruptedException，或调用 interrupted 和 isInterrupted )，A 中的操作结果对 B 都是可见的。

7，终结器规则

一个对象的构造函数必须在它的 finalize() 方法调用时执行完。
根据这条原则，可以确保在对象的 finalize() 方法执行时，该对象的所有字段值都是可见的。

8，传递性规则

如果操作A Happens-Before B，B Happens-Before C，那么可以得出操作 A Happens-Before C。

下面我们在深入思考一下，Happens-Before 原则到底是如何解决变量可见性问题的？

我们已经知道，导致多线程间可见性问题的两个“罪魁祸首”是 CPU缓存 和 重排序。那么如果要保证多个线程间共享的变量对每个线程都及时可见，一种极端的做法就是禁止使用所有的重排序和CPU缓存。即关闭所有的编译器、操作系统和处理器的优化，所有指令顺序全部按照程序代码书写的顺序执行。去掉 CPU 高速缓存，让 CPU 的每次读写操作都直接与主存交互。
当然，上面的这种极端方案是绝对不可取的，因为这会极大影响处理器的计算性能，并且对于那些非多线程共享的变量是不公平的。

重排序和 CPU 高速缓存有利于计算机性能的提高，但却对多CPU处理的一致性带来了影响。为了解决这个矛盾，我们可以采取一种折中的办法。我们用分割线把整个程序划分成几个程序块，在每个程序块内部的指令是可以重排序的，但是分割线上的指令与程序块的其它指令之间是不可以重排序的。在一个程序块内部，CPU 不用每次都与主内存进行交互，只需要在 CPU 缓存中执行读写操作即可，但是当程序执行到分割线处，CPU 必须将执行结果同步到主内存或从主内存读取最新的变量值。那么，Happens-Before 规则就是定义了这些程序块的分割线。