解决并发编程可见性、有序性问题

1. 什么是java 内存模型

解决可见性、有序性问题最直接的办法就是禁用缓存和编译优化。

Java 内存模型规范了JVM 如何提供按需禁用缓存和编译优化的方法，包括（volatile、synchronized 和final 三个关键字 + 六项Happens-Before 规则）：

// 以下代码来源于【参考1】
class VolatileExample {
  int x = 0;
  volatile boolean v = false;
  public void writer() {
    x = 42;
    v = true;
  }
  public void reader() {
    if (v == true) {
      // 这里x会是多少呢？
    }
  }
}

在jdk1.5 之前，x 的值可能是42，也可能是0；如果在jdk1.5 后，那么x 的值一定为42. 这是因为jdk1.5 版本对volatile 进行了增强。
增强的规则就是一项Happens-Before 规则。

详解Happens-Before 规则（6个）：

1. 程序的顺序性规则

在同一个线程中，按照程序的顺序执行，前面的操作Happens-Before 于后续的操作（前面的操作对后续的操作可见）。也就是上面的代码中x=42 后面v=ture 的操作是可见的。

2. volatile 变量规则

对一个volatile 变量的写操作 Happens-Before 与后续对这个volatile 变量的读操作（即一个volatile 变量的写操作对后续对这个变量的读操作是可见的，意思就是禁用缓存）。

3. 传递性

image.png

这里参合进“程序顺序性规则 & volatile 变量规则” 读变量x 应该得到的是x=42 而不可能读到x=0.
因为：虽然x 没有被volatile 变量修饰，但是利用“程序的顺序性规则” 写 x=42 对于v=true 的可见的；又v 是volatile 修饰的，所以对于线程A 的写操作和线程B 的读操作是可见的；对于线程B 对x 变量的读操作根据“传递性”自然是可见的。

4. 管程中的锁规则

管程中的锁在java 里是隐式实现的，如下面的代码在进入同步块之前会加锁，执行完代码后会自动解锁。

synchronized (this) { //此处自动加锁
// x是共享变量,初始值=10
   if (this.x < 12) {
     this.x = 12; 
   }  
} //此处自动解锁
如果 x 的初始值x=10，线程A 执行完x=12 的操作后（执行完自动释放掉锁），那么线程B 访问x 的时候得到的值应该是12。这个值会被刷新到共享内存中

5. 线程的start（）规则

主线程A 中启动子线程B 后，子线程能够看到主线程在启动子线程B 前的操作。

6. 线程join（）规则

在线程A 中调用线程B 的join() 方法并成功返回，则线程B 中的任意操作Happens-Before 于该join() 操作的返回。

Thread B = new Thread(()->{
 // 此处对共享变量var修改
 var = 66;
});
// 例如此处对共享变量修改，
// 则这个修改结果对线程B可见
// 主线程启动子线程
B.start();
B.join()
// 子线程所有对共享变量的修改
// 在主线程调用B.join()之后皆可见！！！
// 此例中，var==66

告诉编译器让优化更好一点 —> final 关键字

volatile 为的是禁用缓存以及编译优化。

在jdk1.5 之后，java 内存模型对final 类型变量的重排序进行了约束，现在只要提供正确构造函数没有“逸出”就不会有问题。

// 以下代码来源于【参考1】
final int x;
// 错误的构造函数
public FinalFieldExample() { 
   x = 3;
   y = 4;
  // 此处就是讲this逸出，
   global.obj = this;
}
线程通过 global.obj 读取 x 是有可能读到 0 的。因此我们一定要避免“逸出”。

---

java 语言中，Happens-Before 本质上就是一种可见性，A Happens-Before B，以为着A 事件对于B 事件是可见的。
线程1 上发生了事件A，线程2上发生了事件B， Happens-Before 保证了线程2 上也能看到事件A。