基础篇深入JMM内存模型解析volatilesynchronized的内存语义

先介绍下多过程多线程在 linux 几种通信形式

管道：管道的本质是一个内核缓冲区，须要通信的两个过程各在管道的两端，过程利用管道传递信息
信号：信号是软件档次上对中断机制的一种模仿，过程不用阻塞期待信号的达到，信号能够在用户空间过程和内核之间间接交互
音讯队列：音讯队列是音讯的链表，寄存在内存中并由音讯队列标识符标识，容许多个过程向它写入与读取音讯
共享内存：多个过程能够能够间接读写同一块内存空间，是针对其余通信机制运行效率较低而设计的
信号量：信号量本质上就是一个标识可用资源数量的计数器，它的值总是非负整数
套接字：套接字可用于不同机器之间的过程间通信。有两种类型的套接字：基于文件的和面向网络(socket)

java 设计上则是基于共享内存来实现过程，线程的通信

1.1 线程 A 须要和线程 B 交互，则须要更新工作内存的共享变量正本到主存，而后线程 B 去主存读取更新后的变量
1.2 java 线程之间的通信是由 JMM 管制的，JMM 决定线程对共享变量的写入何时对另一线程可见。共享变量存在主存，线程领有本人的工作内存(一个形象的概念，它笼罩了缓存，写缓冲区，寄存器等)

处理器的高速倒退，CPU 的性能和内存性能差距拉大，为了解决问题，CPU 设置多级缓存，例如 L1、L2、L3 高速缓存(Cache)。
和 JMM 的内存布局类似，前者是零碎级别，解决缓存一致性问题；后者是利用级别的，解决的是内存一致性问题
这些高速缓存个别都是独属于 CPU 外部的，对其余 CPU 不可见，此时又会呈现缓存和主存的数据不统一景象，CPU 的解决方案有两种
- 总线锁定：当某个 CPU 解决数据时，通过锁定系统总线或者是内存总线，让其余 CPU 不具备拜访内存的拜访权限，从而保障了缓存的一致性
- 缓存一致性协定(MESI)：缓存一致性协定也叫缓存锁定，缓存一致性协定会阻止两个以上 CPU 同时批改映射雷同主存数据的缓存正本

MESI 实现是依附处理器应用 嗅探技术 保障它的外部缓存、零碎主内存和其余处理器的缓存的数据在总线上保持一致
例：处理器打算回写脏内存地址，而此内存处于共享状态(Share)；那么其余处理器会嗅探到，并将使本身的对应的缓存行有效，在下次访问相应内存地址时，刷新该缓存行

缓存数据状态有如下四种(MESI):

缓存状态	形容
M(Modifed)	在缓存行中被标记为 Modified 的值，与主存的值不同，这个值将会在它被其余 CPU 读取之前写入内存，并设置为 Shared
E(Exclusive)	该缓存行对应的主存内容只被该 CPU 缓存，值和主存统一，被其余 CPU 读取时置为 Shared，被其余 CPU 写时置为 Modified
S(Share)	该值也可能存在其余 CPU 缓存中，然而它的值和主存统一
I(Invalid)	该缓存行数据有效，须要时需从新从主存载入

为进步程序性能，编译器和处理器常常会对指令做重排序，别离是 编译器优化的重排序 、 指令并行级别的重排序 ， 内存零碎的重排序。

编译器级别的指令重排序，可由 JMM 规定禁止 特定类型 的指令重排；对于处理器级别的则是插入特定类型的 内存屏障指令，以此禁止特定类型的重排序；内存零碎的重排序则由解决零碎保障执行程序的一致性
CPU 的设计者提供内存屏障机制，是将对共享变量读写的 高速缓存的强一致性控制权 (MESI 的机制) 交给了程序员或编译器
这里介绍两种处理器级别的 内存屏障指令
- 写内存屏障：该屏障之前的写操作先于之后的写操作；在指令后插入 StoreBarrier，能让写入缓存中的最新数据更新写入主内存，让其余线程可见
- 读内存屏障：该屏障之前的读操作先于之后的读操作；在指令前插入 LoadBarrier，让高速缓存中的数据生效，强制从主内存加载数据
内存屏障有两个作用：阻止屏障两侧的指令重排序 ； 强制把写缓冲区 / 高速缓存中的脏数据等写回主内存，让缓存中相应的数据生效
JAVA 的 内存屏障指令，根本能够了解为在 CPU 内存屏障指令上二次封装

JAVA 内存屏障指令	作用形容
Store1;StoreStore;Store2	确保 Store1 数据对其余处理器可见 ( 刷新到内存)，先于 Store2 及所有后续存储指令的存储。
Load1;LoadStore;Store2	确保 Load1 数据装载先于 Store2 及所有后续存储指令的存储。
Store1;StoreLoad;Load2	确保 Store1 数据对其余处理器可见 ( 刷新到内存 ) 先于 Load2 及所有后续装载指令的装载。
Load1;LoadLoad;Load2	确保 Load1 数据的装载，先于 Load2 及所有后续装载指令的装载。

非凡的是 StoreLoad，会使该屏障之前的所有内存拜访指令 (装载和存储指令) 实现之后，才执行该屏障之后的内存拜访指令；是一个”全能型”的屏障，它同时具备其余三个屏障的成果
用一句话形容 java 内存屏障的目标：把当前工作内存的数据全副刷新到主内存，并且其余工作内存的共享变量全副生效，真正须要用时再读取主存最新的值

内存屏障是绝对于 jvm，cpu 级别的内存一致性 (内存可见性) 的解决方案；为了让 java 程序员更容易了解，jsr-133 应用 happens-before 的概念来阐明不同操作之间的内存可见性
- 程序秩序规定：同一个线程，任意一操作 happens-before 同线程之后的全副操作
- 监视器锁 (synchronized) 规定：对一个监视器锁的解锁，happens-before 随后对这个锁的加锁
- volatile 变量规定：对 volatile 变量的写操作，happens-before 该 volatile 变量之后的任意读操作
- 传递性：如果 A 先于 B；B 先于 C；则 A 先于 C
happens-before 局部规定是基于内存屏障实现的

class Count{
    int a = 0;
    public synchronized void writer(){// 1 
        a++; //2
    } //3
    public synchronized void reader(){// 4 
        int i = a; //5 
    } //6
}

依据程序秩序规定，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。执行后果如下图

线程开释锁时内存语义：JMM 会把该线程对应的工作内存中的共享变量刷新到主内存中
线程获取锁时内存语义：JMM 会把该线程对应的工作内存置为有效

volatile 变量具备 可见性，Java 线程内存模型确保所有线程看到这个变量的值是最新的，并且单个 volatile 变量的读 / 写具备原子性；java 编译器对 volatile 变量解决如下
- 在每个 volatile 写操作的后面插入一个 StoreStore 屏障
- 在每个 volatile 写操作的前面插入一个 StoreLoad 屏障
- 在每个 volatile 读操作的后面插入一个 LoadLoad 屏障
- 在每个 volatile 读操作的前面插入一个 LoadStore 屏障
留神 i ++ 是复合操作，即便 i 是 volatile 变量，也不保障 i ++ 是原子操作

volatile Object instance;
instance = new Object();
// 相应汇编代码
0x01a3de1d: movb $0×0,0×1104800(%esi);0x01a3de24: lock addl $0×0,(%esp);

当 volatile 变量润饰的共享变量进行写操作的反汇编代码会呈现0x01a3de24: lock addl $0×0,(%esp)，其实就是插入了内存屏障导致的后果，lock 示意 volatile 变量写时被缓存锁定了(MESI 协定)，作用如下
- 禁止指令重排序
- 将以后处理器缓存行的数据写回到零碎内存
- 这个写回内存的操作会使在其余 CPU 里缓存了该内存地址的数据有效

int a = 0; volatile boolean v = false;

线程 A
a = 1;    //1 
v = true; //2

线程 B
v = true; //3
System.out.println(a);//4

依据程序秩序规定，1 happens-before 2;3 happens-before 4。依据 volatile 变量规定，2 happens-before 3。依据 happens-before 的传递性规定，1 happens-before 4。程序的执行后果体现如下图

volatile 写的内存语义：写 volatile 变量时，JMM 会把该线程对应的本地内存中的共享变量值刷新到主内存
volatile 读的内存语义：读一个 volatile 变量时，JMM 会把该线程对应的本地内存置为有效。线程接下来将从主内存中读取共享变量
非根本字段不应该用 volatile 润饰。其起因是 volatile 润饰对象或数组时，只能保障他们的援用地址的可见性

final 写内存语义：
- 在构造函数内对一个 final 域的写入，与随后把这个被结构对象的援用赋值给一个援用变量，这两个操作之间不能重排序。保障对象被援用之前，fianl 域里的变量都是被初始化的
- 实现原理：编译器会在 final 域的写之后，构造函数 return 之前，插入一个 StoreStore 屏障。这个屏障禁止处理器把 final 域的写重排序到构造函数之外。
```
public class Example { 
    int i; // 一般类型
    final int j; // 援用类型 
    public Example () { // 构造函数 
        i = 0;  j = 1;
    }
    public static void writer () { // 写线程 A 执行 
        obj = new Example ();}
    public static void reader () { // 读线程 B 执行 
        Example object = obj; // 读对象援用 
        int a = object.i; // 读一般域 
        int b = object.j; // 读 final 域 
    }
}
```
- final 只会禁止对其润饰变量的写操作，被重排序到构造函数之外；一般变量 i 的赋值可能会被重排到序构造函数之外
- A 线程创立 obj，可能让线程 B 拿到初始化一半的 obj；final 变量 j 被初始化，而一般变量 i 还没初始化
- 疑难：内存屏障不是会禁止指令重排吗？集体猜测应该是编译器先重排序，此时一般变量曾经在结构器外了，再依据 final 类型插入内存屏障。下面的代码执行可能有如下状况：

final 读内存语义
- 首次读一个蕴含 final 域的对象的援用，与随后首次读这个 final 域，这两个操作之间不能重排序
- 实现原理：要求编译器在读 final 域的操作后面插入一个 LoadLoad 屏障

当应用 final 润饰援用对象或者数组时，final 只保障在结构器返回之前对援用对象的操作先于结构器返回之后的操作

public class Example {final int[] intArray; // intArray 是援用类型 
    public Example () { // 构造函数 
        intArray = new int[1]; 
        intArray[0] = 1; // 此操作对获取该对象援用的线程是可见的
    }
}

public class Instance {                         // 1
    private static Instance instance;           // 2
    public static Instance getInstance() {      // 3
        if (instance == null) {                 // 4: 第一次查看
            synchronized (Instance.class) {     // 5: 加锁
                if (instance == null)           // 6: 第二次查看
                    instance = new Instance();  // 7: 问题的本源出在这里}                                   // 8
        }                                       // 9
        return instance;                        // 10
    }                                           // 11
}

代码第 7 行 instance=new Singleton(); 创立了一个对象。这一行代码能够合成为如下的 3 行伪代码

memory = allocate(); // A1：调配对象的内存空间 
ctorInstance(memory); // A2：初始化对象 
instance = memory; // A3：设置 instance 指向刚调配的内存地址

如果 2 和 3 之间重排序之后的程序如下

memory = allocate(); // A1：调配对象的内存空间 
instance = memory;  //A3：instance 指向刚调配的内存地址，此时对象还没有被初始化
ctorInstance(memory); // A2：初始化对象

如果产生 A3、A2 重排序，线程是不保障赋值和初始化对象 两步骤操作后果会一起同步到主存
<font color=’red’> 因而第二个线程执行到 if (instance == null);// 4: 第一次查看 时，可能会失去一个刚调配的内存而没初始化的对象(此时没有加锁，锁的 happens-before 规定不实用)</font>
相应的两个解决办法
- 在锁内应用 volatile 润饰 instance，volatile 保障指令禁止重排序，并且保障变量的内存可见性：private volatile static Instance instance;
- 应用类加载器的全局锁，在执行类的初始化期间，JVM 会去获取一个锁；这个锁能够同步多个线程对同一个类的初始化，每个线程都会试图获取该类的全局锁去初始化类
```
public class InstanceFactory { 
    private static class InstanceHolder {public static Instance instance = new Instance();
    }
    public static Instance getInstance() {
        // 这里将导致 InstanceHolder 类被初始化 
        return InstanceHolder.instance ; 
    } 
}
```

伪共享
- 后面介绍到每个 CPU 都有属于本人的高速缓存，然而缓存数据大小是怎么的呢？
- 这个大小并不是咱们需要存多大就存多大的，而是一个固定的大小 -64 字节，缓存的加载更新都是以间断的 64 字节内存为单位，称之为缓存行
- 一缓存行是能够存在多个变量的，比方 long 类型(64 位 == 8 字节)，能够存入 8 个

如果变量 A 和变量 B 是在同一间断的内存，CPU 缓存加载 A 时，B 也会被读取；反之亦然，A 的脏回写导致在其余 CPU 相应内存生效的同时，同一缓存行的 B 内存也被标识为 Modified(同舟共渡，一起翻船)
构想变量 A 和 B 没有关联，却刚好在同一缓存行；而后 A 被 CPU- X 解决，B 被 CPU- Y 解决；因为 CPU- X 对 A 的缓存更新而导致 B 的缓存生效；CPU- Y 要解决 B，则要读取更新后的缓存行 (B 理论是没被更新)，造成没必要的内存读取开销。这就是 伪共享

伪共享的解决办法：

<br/> 1- 填充字节，将对应的变量填充到缓存行的大小。如上面定义的类，申明额定的属性

public final static class FilledLong {
    /**value 加 p1 - p6；加对象头 8 个字节正好等于一缓存行的大小 */
    //markWord + klass (32 位机,64 位是 16 字节) 8 字节 
    public volatile long value = 0L; // 8 字节
    public long p1, p2, p3, p4, p5, p6; //48 字节
}

2- 应用 jdk 的注解 @Contended 润饰变量，jvm 会主动将变量填充到缓存行的大小。留神的是须要退出启动参数 -XX:-RestrictContended

java 并发编程的艺术（书籍）
Linux 过程间通信的几种形式
java 内存屏障
搞懂内存屏障 - 指令与 JMM
杂谈什么是伪共享

基础篇深入JMM内存模型解析volatilesynchronized的内存语义

1 java 内存模型，JMM(JAVA Memory Model)

2 CPU 高速缓存、MESI 协定

3 指令重排序和内存屏障指令

4 happen-before 准则

5 synchronized 内存语义

6 volatile 的内存语义

7 final 内存语义

8 synchronized,volatile 内存语义的原理梳理

9 应用题：提早加载双重锁定是否真的平安

10 题外话：伪共享(false sharing)

关注公众号，大家一起交换

参考文章