起源：《Java 高并发编程详解多线程与架构设计》，汪文君著
章节：第十二、十三章

本文是两章的笔记整顿。

2 `CPU`缓存

计算机中的所有运算操作都是由 CPU 实现的，CPU指令执行过程须要波及数据读取和写入操作，然而 CPU 只能拜访处于内存中的数据，而内存的速度和 CPU 的速度是远远不对等的，因而就呈现了缓存模型，也就是在 CPU 和内存之间退出了缓存层。个别古代的 CPU 缓存层分为三级，别离叫 L1 缓存、L2缓存和 L3 缓存，简略图如下：

L1缓存：三级缓存中访问速度最快，然而容量最小，另外 L1 缓存还被划分成了数据缓存（L1d，data首字母）和指令缓存（L1i，instruction首字母）
L2缓存：速度比 L1 慢，然而容量比 L1 大，在古代的多核 CPU 中，L2个别被单个核独占
L3缓存：三级缓存中速度最慢，然而容量最大，古代 CPU 中也有 L3 是多核共享的设计，比方 zen3 架构的设计

缓存的呈现，是为了解决 CPU 间接拜访内存效率低下的问题，CPU进行运算的时候，将须要的数据从主存复制一份到缓存中，因为缓存的访问速度快于内存，在计算的时候只须要读取缓存并将后果更新到缓存，运算完结再将后果刷新到主存，这样就大大提高了计算效率，整体交互图简略如下：

尽管缓存的呈现，大大提高了吞吐能力，然而，也引入了一个新的问题，就是缓存不统一。比方，最简略的一个 i++ 操作，须要将内存数据复制一份到缓存中，CPU读取缓存值并进行更新，先写入缓存，运算完结后再将缓存中新的刷新到内存，具体过程如下：

读取内存中的 i 到缓存中
CPU读取缓存 i 中的值
对 i 进行加 1 操作
将后果写回缓存
再将数据刷新到主存

这样的 i++ 操作在单线程不会呈现问题，但在多线程中，因为每个线程都有本人的工作内存（也叫本地内存，是线程本人的缓存），变量 i 在多个线程的本地内存中都存在一个正本，如果有两个线程执行 i++ 操作：

假如两个线程为 A、B，同时假如 i 初始值为 0
线程 A 从内存中读取 i 的值放入缓存中，此时 i 的值为 0，线程 B 也同理，放入缓存中的值也是 0
两个线程同时进行自增操作，此时 A、B 线程的缓存中，i的值都是 1
两个线程将 i 写入主内存，相当于 i 被两次赋值为 1
最终后果是 i 的值为 1

这个就是典型的缓存不统一问题，支流的解决办法有：

总线加锁
缓存一致性协定

这是一种乐观的实现形式，具体来说，就是通过处理器收回 lock 指令，锁住总线，总线收到指令后，会阻塞其余处理器的申请，直到占用锁的处理器实现操作。特点是只有一个抢到总线锁的处理器运行，然而这种形式效率低下，一旦某个处理器获取到锁其余处理器只能阻塞期待，会影响多核处理器的性能。

图示如下：

缓存一致性协定中最闻名的就是 MESI 协定，MESI保障了每一个缓存中应用的共享变量的正本都是统一的。大抵思维是，CPU操作缓存中的数据时，如果发现该变量是一个共享变量，操作如下：

读取：不做其余解决，只是将缓存中数据读取到寄存器中
写入：发出信号告诉其余 CPU 将该变量的缓存行设置为有效状态（Invalid），其余 CPU 进行该变量的读取时须要到主存中再次获取

具体来说，MESI中规定了缓存行应用 4 种状态标记：

M：Modified，被批改
E：Exclusive，独享的
S：Shared，共享的
I：Invalid，有效的

无关 MESI 具体的实现超出了本文的范畴，想要具体理解能够参考此处或此处。

3 `JMM`

看完了 CPU 缓存再来看一下 JMM，也就是Java 内存模型，指定了 JVM 如何与计算机的主存进行工作，同时也决定了一个线程对共享变量的写入何时对其余线程可见，JMM定义了线程和主内存之间的形象关系，具体如下：

共享变量存储于主内存中，每个线程都能够拜访
每个线程都有公有的工作内存或者叫本地内存
工作内存只存储该线程对共享变量的正本
线程不能间接操作主内存，只有先操作了工作内存之后能力写入主内存
工作内存和 JMM 内存模型一样也是一个抽象概念，其实并不存在，涵盖了缓存、寄存器、编译期优化以及硬件等

简略图如下：

与 MESI 相似，如果一个线程批改了共享变量，刷新到主内存后，其余线程读取工作内存的时候发现缓存生效，会从主内存再次读取到工作内存中。

而下图示意了 JVM 与计算机硬件调配的关系：

文章都看了大半了还没到 volatile？别急别急，先来看看并发编程中的三个重要个性，这对正确理解volatile 有很大的帮忙。

原子性就是在一次或屡次操作中：

要么所有的操作全副都失去了执行，且不会受到任何因素的烦扰而中断
要么所有的操作都不执行

一个典型的例子就是两个人转账，比方 A 向 B 转账 1000 元，那么这蕴含两个根本的操作：

A 的账户扣除 1000 元
B 的账户减少 1000 元

这两个操作，要么都胜利，要么都失败，也就是不能呈现 A 账户扣除 1000 然而 B 账户金额不变的状况，也不能呈现 A 账户金额不变 B 账户减少 1000 的状况。

须要留神的是两个原子性操作联合在一起未必是原子性的，比方 i++。实质上来说，i++ 波及到了三个操作：

get i
i+1
set i

这三个操作都是原子性的，然而组合在一起（i++）就不是原子性的。

另一个重要的个性是可见性，可见性是指，一个线程对共享变量进行了批改，那么另外的线程能够立刻看到批改后的最新值。

一个简略的例子如下：

public class Main {
    private int x = 0;
    private static final int MAX = 100000;
    public static void main(String[] args) throws InterruptedException {Main m = new Main();
        Thread thread0 = new Thread(()->{while(m.x < MAX) {++m.x;}
        });

        Thread thread1 = new Thread(()->{while(m.x < MAX){ }
            System.out.println("finish");
        });

        thread1.start();
        TimeUnit.MILLISECONDS.sleep(1);
        thread0.start();}
}

线程 thread1 会始终运行，因为 thread1 把x读入工作内存后，会始终判断工作内存中的值，因为 thread0 扭转的是 thread0 工作内存的值，并没有对 thread1 可见，因而永远也不会输入 finish，应用jstack 也能够看到后果：

有序性是指代码在执行过程中的先后顺序，因为 JVM 的优化，导致了代码的编写程序未必是代码的运行程序，比方上面的四条语句：

int x = 10;
int y = 0;
x++;
y = 20;

有可能 y=20 在x++前执行，这就是指令重排序。一般来说，处理器为了进步程序的效率，可能会对输出的代码指令做肯定的优化，不会严格依照编写程序去执行代码，但能够保障最终运算后果是编码时的冀望后果，当然，重排序也有肯定的规定，须要严格遵守指令之间的数据依赖关系，并不是能够任意重排序，比方：

int x = 10;
int y = 0;
x++;
y = x+1;

y=x+1就不能先优于 x++ 执行。

在单线程下重排序不会导致预期值的扭转，但在多线程下，如果有序性得不到保障，那么将可能呈现很大的问题：

private boolean initialized = false;
private Context context;
public Context load(){if(!initialized){context = loadContext();
        initialized = true;
    }
    return context;
}

如果产生了重排序，initialized=true排序到了 context=loadContext() 的后面，假如两个线程 A、B 同时拜访，且 loadContext() 须要肯定耗时，那么：

线程 A 通过判断后，先设置布尔变量的值为 true，再进行loadContext() 操作
线程 B 中因为布尔变量被设置为true，会间接返回一个未加载实现的context

5 `volatile`

好了终于到了 volatile 了，后面说了这么多，目标就是为了能彻底了解和明确volatile。这部分分为四个大节：

volatile的语义
如何保障有序性以及可见性
实现原理
应用场景
与 synchronized 区别

先来介绍一下 volatile 的语义。

被 volatile 润饰的实例变量或者类变量具备两层语义：

保障了不同线程之间对共享变量操作时的可见性
禁止对指令进行重排序操作

先说论断：

volatile能保障可见性
volatile能保障有序性
volatile不能保障原子性

上面别离进行介绍。

Java中保障可见性有如下形式：

volatile：当一个变量被 volatile 润饰时，对共享资源的读操作会间接在主内存中进行（精确来说也会读取到工作内存中，然而如果其余线程进行了批改就必须从主内存从新读取），写操作是先批改工作内存，然而批改完结后立刻刷新到主内存中
synchronized：synchronized一样能保障可见性，可能保障同一时刻只有一个线程获取到锁，而后执行同步办法，并且确保锁开释之前，变量的批改被刷新到主内存中
应用显式锁 Lock：Lock 的lock办法能保障同一时刻只有一个线程可能获取到锁而后执行同步办法，并且确保锁开释之前可能将对变量的批改刷新到主内存中

具体来说，能够看一下之前的例子：

public class Main {
    private int x = 0;
    private static final int MAX = 100000;
    public static void main(String[] args) throws InterruptedException {Main m = new Main();
        Thread thread0 = new Thread(()->{while(m.x < MAX) {++m.x;}
        });

        Thread thread1 = new Thread(()->{while(m.x < MAX){ }
            System.out.println("finish");
        });

        thread1.start();
        TimeUnit.MILLISECONDS.sleep(1);
        thread0.start();}
}

下面说过这段代码会一直运行，始终没有输入，就是因为批改后的 x 对线程 thread1 不可见，如果在 x 的定义中加上了 volatile，就不会呈现没有输入的状况了，因为此时对x 的批改是线程 thread1 可见的。

JMM中容许编译期和处理器对指令进行重排序，在多线程的状况下有可能会呈现问题，为此，Java同样提供了三种机制去保障有序性：

volatile
synchronized
显式锁Lock

另外，对于有序性不得不提的就是 Happens-before 准则。Happends-before准则说的就是如果两个操作的执行秩序无奈从该准则推导进去，那么就无奈保障有序性，JVM或处理器能够任意重排序。这么做的目标是为了尽可能进步程序的并行度，具体规定如下：

程序秩序规定：在一个线程内，代码依照编写时的秩序执行，编写在前面的操作产生与编写在后面的操作之后
锁定规定：如果一个锁处于锁定状态，则 unlock 操作要后行产生于对同一个锁的 lock 操作
volatile变量规定：对一个变量的写操作要早于对这个变量之后的读操作
传递规定：如果操作 A 先于操作 B，操作 B 先于操作 C，那么操作 A 先于操作 C
线程启动规定：Thread对象的 start() 办法后行产生于对该线程的任何动作
线程中断规定：对线程执行 interrupt() 办法必定要优于捕捉到中断信号，换句话说，如果收到了中断信号，那么在此之前必然调用了interrupt()
线程终结规定：线程中所有操作都要后行产生于线程的终止检测，也就是逻辑单元的执行必定要产生于线程终止之前
对象终结规定：一个对象初始化的实现后行产生于 finalize() 之前

对于 volatile，会间接禁止对指令重排，然而对于volatile 前后无依赖关系的指令能够随便重排，比方：

int x = 0;
int y = 1;
//private volatile int z;
z = 20;
x++;
y--;

在 z=20 之前，先定义 x 或先定义 y 并没有要求，只须要在执行 z=20 的时候，能够保障 x=0,y=1 即可，同理，x++或 y-- 具体先执行哪一个并没有要求，只须要保障两者执行在 z=20 之后即可。

在 Java 中，所有对根本数据类型变量的读取赋值操作都是原子性的，对援用类型的变量读取和赋值也是原子性的，然而：

将一个变量赋值给另一个变量的操作不是原子性的，因为波及到了一个变量的读取以及一个变量的写入，两个原子性操作联合在一起就不是原子性操作
多个原子性操作在一起就不是原子性操作，比方i++
JMM只保障根本读取和赋值的原子性操作，其余的均不保障，如果须要具备原子性，那么能够应用 synchronized 或Lock，或者 JUC 包下的原子操作类

也就是说，volatile并不能保障原子性，例子如下：

public class Main {
    private volatile int x = 0;
    private static final CountDownLatch latch = new CountDownLatch(10);

    public void inc() {++x;}

    public static void main(String[] args) throws InterruptedException {Main m = new Main();
        IntStream.range(0, 10).forEach(i -> {new Thread(() -> {for (int j = 0; j < 1000; j++) {m.inc();
                }
                latch.countDown();}).start();});
        latch.await();
        System.out.println(m.x);
    }
}

最初输入的 x 的值会少于10000，而且每次运行的后果也并不相同，至于起因，能够从两个线程 A、B 开始剖析，图示如下：

0-t1：线程 A 将 x 读入工作内存，此时x=0
t1-t2：线程 A 工夫片完，CPU调度线程 B，线程 B 将 x 读入工作内存，此时x=0
t2-t3：线程 B 对工作内存中的 x 进行自增操作，并更新到工作内存中
t3-t4：线程 B 工夫片完，CPU调度线程 A，同理线程 A 对工作内存中的 x 自增
t4-t5：线程 A 将工作内存中的值写回主内存，此时主内存中的值为x=1
t5当前：线程 A 工夫片完，CPU调度线程 B，线程 B 也将本人的工作内存写回主内存，再次将主内存中的 x 赋值为 1

也就是说，多线程操作的话，会呈现两次自增然而实际上只进行一次数值批改的操作。想要 x 的值变为 10000 也很简略，加上 synchronized 即可：

new Thread(() -> {synchronized (m) {for (int j = 0; j < 1000; j++) {m.inc();
        }
    }
    latch.countDown();}).start();

后面曾经晓得，volatile能够保障有序性以及可见性，那么，具体是如何操作的呢？

答案就是一个 lock; 前缀，该前缀实际上相当于一个内存屏障，该内存屏障会为指令的执行提供如下几个保障：

确保指令重排序时不会将其前面的代码排到内存屏障之前
确保指令重排序时不会将其后面的代码排到内存屏障之后
确保执行到内存屏障润饰的指令时后面的代码全副执行实现
强制将线程工作内存中的值批改刷新到主存中
如果是写操作，会导致其余线程工作内存中的缓存数据生效

一个典型的应用场景是利用开关进行线程的敞开操作，例子如下：

public class ThreadTest extends Thread{
    private volatile boolean started = true;

    @Override
    public void run() {while (started){}}

    public void shutdown(){this.started = false;}
}

如果布尔变量没有被 volatile 润饰，那么很可能新的布尔值刷新不到主内存中，导致线程不会完结。

5.5 与 `synchronized` 的区别

应用上的区别：volatile只能用于润饰实例变量或者类变量，然而不能用于润饰办法、办法参数、局部变量等，另外能够润饰的变量为 null。但synchronized 不能用于对变量的润饰，只能润饰办法或语句块，而且 monitor 对象不能为null
对原子性的保障：volatile无奈保障原子性，然而 synchronized 能够保障
对可见性的保障：volatile与 synchronized 都能保障可见性，然而 synchronized 是借助于 JVM 指令 monitor enter/monitor exit 保障的，在 monitor exit 的时候所有共享资源都被刷新到主内存中，而 volatile 是通过 lock; 机器指令实现的，迫使其余线程工作内存生效，须要到主内存加载
对有序性的保障：volatile可能禁止 JVM 以及处理器对其进行重排序，而 synchronized 保障的有序性是通过程序串行化执行换来的，并且在 synchronized 代码块中的代码也会产生指令重排的状况
其余区别：volatile不会使线程陷入阻塞，但 synchronized 会

关于java:Java高并发学习笔记四volatile关键字

1 起源

2 `CPU`缓存

2.1 缓存模型

2.2 缓存一致性问题

2.2.1 总线加锁

2.2.2 缓存一致性协定

3 `JMM`

4 并发编程的三个个性

4.1 原子性

4.2 可见性

4.3 有序性

5 `volatile`

5.1 语义

5.2 如何保障可见性以及有序性

5.2.1 可见性

5.2.2 有序性

5.2.3 原子性

5.3 实现原理

5.4 应用场景

5.5 与 `synchronized` 的区别

1 起源

2 CPU缓存

2.1 缓存模型

2.2 缓存一致性问题

2.2.1 总线加锁

2.2.2 缓存一致性协定

3 JMM

4 并发编程的三个个性

4.1 原子性

4.2 可见性

4.3 有序性

5 volatile

5.1 语义

5.2 如何保障可见性以及有序性

5.2.1 可见性

5.2.2 有序性

5.2.3 原子性

5.3 实现原理

5.4 应用场景

5.5 与 synchronized 的区别

2 `CPU`缓存

3 `JMM`

5 `volatile`

5.5 与 `synchronized` 的区别