Java如何解决可见性和有序性问题-Java内存模型

2019-07-18 本文已影响0人颓靡浪荡君

可见性，是由cpu的缓存导致的；有序性，是由编译优化导致的。那么解决可见性、有序性最直接的办法就是禁止使用缓存和编译优化。虽然这样解决了问题，但是程序的性能就会出问题。最合理的办法就是按需禁止使用缓存以及编译优化。所以，为了解决可见性和有序性的问题，只需要提供给程序员按需禁用缓存和编译优化的方法即可，即Java内存模型。

Java内存模型

Java内存模型是一种很复杂的规范，站在我们程序员的视角，本质上可以理解为Java内存模型规范了JVM如果提供了按需禁止使用缓存和编译优化的方法。具体来说，这些方法包括volatile、synchronized和final三个关键字，以及六项Happens-Before原则。

volatile关键字

volatile关键字，主要是用来声明变量，用它声明的变量，就是告诉编译器，对这个变量的读写，不能使用CPU缓存，必须从内存中读取或写入。

class VolatileExample {
    int x = 0;
    volatile boolean v = false;
    public void writer() {
        x = 42;
        v = true;
    }
    public void reader() {
        if(v == true) {
            System.out.println("x = " +　ｘ);
        }
    }
}

假设有两个线程Ａ和Ｂ，线程Ａ先执行writer()方法，按照volatile的语义，会把变量“v = ture”写入内存；线程B执行reader()方法，同样按照volatile语义，线程B会从内存中读取变量v，如果线程B看到“v == true”时，那么它看到的x是多少呢？从直觉上看，应该是42，那实际应该是多少呢？那就要看Java版本，低于1.5版本，可能是42，也可能是0；高于1.5版本，就是42。原因就是1.5版本之后，利用Happens-Before的规则对volatile的语义进行增强。

Happens-Before规则

Happens-Before规则要表达的是，前面的一个操作的结果对后续操作是可见的。与程序员相关的有如下六项：

程序的顺序性原则
该条规则是指在一个线程中，按照程序顺序，前面的操作Happens-Before与后续的任意操作。即上面的示例代码中，在writer()方法中，“x = 42”Happens-Before于“v = true”。
volatile变量规则
该条规则是指对一个volatile变量的写操作，Happens-Before于后续对这个volatile变量的读操作。
传递性
       该条规则是指如果A Happens-Before B，且B Happens-Before C，那么A Happens-Before C。
       就这三条Happens-Before规则而言，上面的代码有如下的结论：
       1.“x = 42”Happens-Before写变量“v = true”，这是根据程序的顺序性规则；
       2.写变量“v = true”Happens-Before读变量“v=true”，这是根据volatile变量规则；
       3.根据传递性，“x=42”Happens-Before读变量"v=true"。
       这也是1.5版本后，利用Happens-Before原则对volatile的语义进行了增强。
管程中的锁规则
该条规则是指一个锁的解锁Happens-Before于后续对这个锁的加锁。
线程start()规则
该条规则是指主线程A启动子线程B后，子线程B能够看到主线程在启动子线程B之前的操作。
线程join()线程
该条规则是指主线程A等待子线程B完成，当子线程B完成后，主线程能够看到子线程的操作。
注意，后两条规则中，所谓的“看到的操作”指的是对共享变量的操作。

final修饰符

final修饰变量时，初衷是告诉编译器：这个变量生而不变。故其他线程能够看到已经初始化的final实例字段，这是安全的。

Java内存模型底层的实现

主要是通过内存屏障（memory barrier）禁止重排序的，即时编译器根据具体的底层体系架构，将这些内存屏障替换成具体的CPU指令。对于编译器而言，内存屏障将限制它所能做的重排序优化。而对于处理器而言，内存屏障将会导致缓存的刷新操作。