我们已经知道，导致可见性的原因是缓存，导致有序性的原因是编译优化。你可能想到解决可见性、有序性最直接的方法就是 禁用缓存和编译优化，但是这样虽然解决了问题，我们程序的性能可就堪忧了。
合理的解决方案就是 按需禁用缓存以及编译优化。那么，如何做到“按需禁用”呢？对于并发程序，何时禁用缓存以及编译优化只有程序员知道，那所谓的“按需禁用”其实就是按照程序员的要求来禁用。所以，为了解决可见性和有序性问题，只要提供给程序员按需禁用缓存和编译优化的方法即可。
而这种方法就是java内存模型。
JAVA内存模型
java内存模型是一个复杂的规范，但是，如果站在我们这些程序员的角度来解读的话，本质上可以理解为，java内存模型规范了JVM如何提供按需禁用缓存和编译优化的方法。具体来说，这些方法包括 volatile、synchronized、final三个关键字以及六项 Happens-Before规则。
Happens-Before规则
1）程序次序规则
在一个 线程内，按照程序代码顺序，书写在前面的操作先行发生于书写在后面的操作。
2）volatile变量规则
这条规则则是针对一个volatile变量的写操作，Happens-Before于后续对这个volatile变量的读操作。
3）传递性
这条规则是指如果A Happens-Before B,B Happens-Before C,则A Happens-Before C。
4） 管程中锁的规则
这条规则是指对一个锁的解锁Happens-Before 于后续对这个锁的加锁。
5）线程start()规则
这条是关于线程启动的。它是指主线程A启动线程B,线程B Happens-Before 线程A启动线程B前的操作
public class jmmDemo {
private static int a=0;
public static void main(String[] args) {
a=40;
new MyThread().start();
}
private static class MyThread extends Thread{
@Override
public void run() {
super.run();
System.out.printf("主线程的操作Happens-Before对子线程的start操作------》a="+a);
}
}
}
6）线程Join()规则
这个规则是关于线程等待的。它是指主线程A等待子线程B完成，当子线程B完成后，主线程A能够看到子线程B的操作。
public class jmmDemo {
private static int a=0;
public static void main(String[] args) {
MyThread myThread=new MyThread();
myThread.start();
try {
myThread.join();
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.printf("子线程的Join操作Happens-Before主线程------》a="+a);
}
private static class MyThread extends Thread{
@Override
public void run() {
super.run();
//此处对共享变量修改
a=40;
}
}
}
volatile
自身特性
1）对一个volatile变量的读，总是能看到对这个volatile变量最后的写入
2）对任意单个volatile变量的读/写具有原子性
volatile写-读的内存含义
1）当写一个volatile变量时，JMM会把该线程对应的本地内存中的共享变量的值刷新到主内存中
2）当读一个volatile变量时，JMM会把该线程对应的本地内存置为无效，线程接下来将从主内存中读取共享变量
总结：从volatile变量的读写操作，就实现了线程间的通信。
Volatile内存语义的实现
为了实现volatile内存语义，JMM对编译器重排序和处理器重排序做了限制。针对编译器重排序制定了如下volatile重排序规则表：
| 是否能排序 | 第二个操作 | ||
| 第一个操作 | 普通读/写 | Volatile写 | Volatile读 |
| 普通读/写 | YES | YES | NO |
| Volatile写 | NO | NO | NO |
| Volatile读 | YES | NO | NO |
- 在每个 volatile 写操作的前面插入一个 StoreStore 屏障。
- 在每个 volatile 写操作的后面插入一个 StoreLoad 屏障。
- 在每个 volatile 读操作的后面插入一个 LoadLoad 屏障。
- 在每个 volatile 读操作的后面插入一个 LoadStore 屏障。
上述内存屏障插入策略非常保守，但它可以保证在任意处理器平台，任意的程序中都能得到正确的 volatile 内存语义。
下面是保守策略下，volatile 写插入内存屏障后生成的指令序列示意图：
上图中的 StoreStore 屏障可以保证在 volatile 写之前，其前面的所有普通写操作已经对任意处理器可见了。这是因为 StoreStore 屏障将保障上面所有的普通写在 volatile 写之前刷新到主内存。
这里比较有意思的是 volatile 写后面的 StoreLoad 屏障。这个屏障的作用是避免 volatile 写与后面可能有的 volatile 读 / 写操作重排序。因为编译器常常无法准确判断在一个 volatile 写的后面，是否需要插入一个 StoreLoad 屏障（比如，一个 volatile 写之后方法立即 return）。
为了保证能正确实现 volatile 的内存语义，JMM 在这里采取了保守策略：在每个 volatile 写的后面或在每个 volatile 读的前面插入一个 StoreLoad 屏障。从整体执行效率的角度考虑，JMM 选择了在每个 volatile 写的后面插入一个 StoreLoad 屏障。
0因为 volatile 写 - 读内存语义的常见使用模式是：一个写线程写 volatile 变量，多个读线程读同一个 volatile 变量。当读线程的数量大大超过写线程时，选择在 volatile 写之后插入 StoreLoad 屏障将带来可观的执行效率的提升。从这里我们可以看到 JMM 在实现上的一个特点：首先确保正确性，然后再去追求执行效率。
下面是在保守策略下，volatile 读插入内存屏障后生成的指令序列示意图：
synchronized
锁的释放 - 获取建立的 happens before 关系
锁是 java 并发编程中最重要的同步机制。锁除了让临界区互斥执行外，还可以让释放锁的线程向获取同一个锁的线程发送消息
class MonitorExample {
int a = 0;
public synchronized void writer() { //1
a++; //2
} //3
public synchronized void reader() { //4
int i = a; //5
……
} //6
}
假设线程 A 执行 writer() 方法，随后线程 B 执行 reader() 方法。根据 happens before 规则，这个过程包含的 happens before 关系可以分为两类：
- 根据程序次序规则，1 happens before 2, 2 happens before 3; 4 happens before 5, 5 happens before 6。
- 根据监视器锁规则，3 happens before 4。
- 根据 happens before 的传递性，2 happens before 5。
上述 happens before 关系的图形化表现形式如下：
在上图中，每一个箭头链接的两个节点，代表了一个 happens before 关系。黑色箭头表示程序顺序规则；橙色箭头表示监视器锁规则；蓝色箭头表示组合这些规则后提供的 happens before 保证。
上图表示在线程 A 释放了锁之后，随后线程 B 获取同一个锁。在上图中，2 happens before 5。因此，线程 A 在释放锁之前所有可见的共享变量，在线程 B 获取同一个锁之后，将立刻变得对 B 线程可见。
锁释放和获取的内存语义
当线程释放锁时，JMM 会把该线程对应的本地内存中的共享变量刷新到主内存中。以上面的 MonitorExample 程序为例，A 线程释放锁后，共享数据的状态示意图如下：
当线程获取锁时，JMM 会把该线程对应的本地内存置为无效。从而使得被监视器保护的临界区代码必须要从主内存中去读取共享变量。下面是锁获取的状态示意图：
下面对锁释放和锁获取的内存语义做个总结：
- 线程 A 释放一个锁，实质上是线程 A 向接下来将要获取这个锁的某个线程发出了（线程 A 对共享变量所做修改的）消息。
- 线程 B 获取一个锁，实质上是线程 B 接收了之前某个线程发出的（在释放这个锁之前对共享变量所做修改的）消息。
- 线程 A 释放锁，随后线程 B 获取这个锁，这个过程实质上是线程 A 通过主内存向线程 B 发送消息。
final
对于 final 域，编译器和处理器要遵守两个重排序规则：
- 在构造函数内对一个 final 域的写入，与随后把这个被构造对象的引用赋值给一个引用变量，这两个操作之间不能重排序。
- 初次读一个包含 final 域的对象的引用，与随后初次读这个 final 域，这两个操作之间不能重排序。
下面，我们通过一些示例性的代码来分别说明这两个规则：
public class FinalExample {
int i; // 普通变量
final int j; //final 变量
static FinalExample obj;
public void FinalExample () { // 构造函数
i = 1; // 写普通域
j = 2; // 写 final 域
}
public static void writer () { // 写线程 A 执行
obj = new FinalExample ();
}
public static void reader () { // 读线程 B 执行
FinalExample object = obj; // 读对象引用
int a = object.i; // 读普通域
int b = object.j; // 读 final 域
}
}
这里假设一个线程 A 执行 writer () 方法，随后另一个线程 B 执行 reader () 方法。下面我们通过这两个线程的交互来说明这两个规则。
写 final 域的重排序规则
写 final 域的重排序规则禁止把 final 域的写重排序到构造函数之外。这个规则的实现包含下面 2 个方面：
- JMM 禁止编译器把 final 域的写重排序到构造函数之外。
- 编译器会在 final 域的写之后，构造函数 return 之前，插入一个 StoreStore 屏障。这个屏障禁止处理器把 final 域的写重排序到构造函数之外。
现在让我们分析 writer () 方法。writer () 方法只包含一行代码：finalExample = new FinalExample ()。这行代码包含两个步骤：
- 构造一个 FinalExample 类型的对象；
- 把这个对象的引用赋值给引用变量 obj。
假设线程 B 读对象引用与读对象的成员域之间没有重排序（马上会说明为什么需要这个假设），下图是一种可能的执行时序：
在上图中，写普通域的操作被编译器重排序到了构造函数之外，读线程 B 错误的读取了普通变量 i 初始化之前的值。而写 final 域的操作，被写 final 域的重排序规则“限定”在了构造函数之内，读线程 B 正确的读取了 final 变量初始化之后的值。
写 final 域的重排序规则可以确保：在对象引用为任意线程可见之前，对象的 final 域已经被正确初始化过了，而普通域不具有这个保障。以上图为例，在读线程 B“看到”对象引用 obj 时，很可能 obj 对象还没有构造完成（对普通域 i 的写操作被重排序到构造函数外，此时初始值 2 还没有写入普通域 i）。
读 final 域的重排序规则
读 final 域的重排序规则如下：
在一个线程中，初次读对象引用与初次读该对象包含的 final 域，JMM 禁止处理器重排序这两个操作（注意，这个规则仅仅针对处理器）。编译器会在读 final 域操作的前面插入一个 LoadLoad 屏障。
初次读对象引用与初次读该对象包含的 final 域，这两个操作之间存在间接依赖关系。由于编译器遵守间接依赖关系，因此编译器不会重排序这两个操作。大多数处理器也会遵守间接依赖，大多数处理器也不会重排序这两个操作。但有少数处理器允许对存在间接依赖关系的操作做重排序（比如 alpha 处理器），这个规则就是专门用来针对这种处理器
reader() 方法包含三个操作：
- 初次读引用变量 obj;
- 初次读引用变量 obj 指向对象的普通域 j。
- 初次读引用变量 obj 指向对象的 final 域 i。
现在我们假设写线程 A 没有发生任何重排序，同时程序在不遵守间接依赖的处理器上执行，下面是一种可能的执行时序：
参考书籍
java并发编程艺术
扫一扫
5427
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
