7.java并发编程之volatile与happends before

最新推荐文章于 2024-03-14 22:32:06 发布

然而,然而

最新推荐文章于 2024-03-14 22:32:06 发布

阅读量62

点赞数

文章标签： java 开发语言缓存

本文链接：https://blog.csdn.net/qq_30635523/article/details/131325735

版权

JMM共享模型之内存

5.1 Java 内存模型

JMM 即 Java Memory Model。

它定义了主存、工作内存抽象概念，底层对应着 CPU 寄存器、缓存、硬件内存、CPU 指令优化等。

JMM 体现在以下几个方面:

原子性 - 保证指令不会受到线程上下文切换的影响

可见性 - 保证指令不会受 cpu 缓存的影响

有序性 - 保证指令不会受 cpu 指令并行优化的影响

5.2 可见性

退不出的循环

先来看一个现象，main 线程对 run 变量的修改对于 t 线程不可见，导致了 t 线程无法停止：

static boolean run = true; public static void main(String[] args) throws InterruptedException { Thread t = new Thread(()->{ while(run){ //System.out.println("stop"); } }); t.start(); sleep(1); run = false; // 线程t不会如预想的停下来 }

为什么呢？分析一下： 1.初始状态， t 线程刚开始从主内存读取了 run 的值到工作内存。 2.因为 t 线程要频繁从主内存中读取 run 的值，JIT 编译器会将 run 的值缓存至自己工作内存中的高速缓存中，减少对主存中 run 的访问，提高效率 3.1 秒之后，main 线程修改了 run 的值，并同步至主存，而 t 是从自己工作内存中的高速缓存中读取这个变量的值，结果永远是旧值

解决方法:volatile

它可以用来修饰成员变量和静态成员变量，他可以避免线程从自己的工作缓存中查找变量的值，必须到主存中获取它的值，线程操作 volatile 变量都是直接操作主存。

volatile:每次读取的时候会判断当前线程的本地缓存是否失效,如果失效,会重新到主内存中加载最新的值。

注意是每次读取的时候。

1.声明static变量 value = 0; 2.A B 2个线程同时读取主内存value=0,并放到线程的本地缓存 3.A修改value=1 并同步到主内存 4.此时B线程的value仍等于0 5.如果B线程再次读取发现value已经失效,会重新再读一次主内存 6.但是如果B线程没有再读取,仍然是旧值！

volatile关键字只能保证可见性，不能保证原子性。

可见性 vs 原子性

前面例子体现的实际就是可见性，它保证的是在多个线程之间，一个线程对 volatile 变量的修改对另一个线程可见，不能保证原子性，仅用在一个写线程，多个读线程的情况：上例从字节码理解是这样的：

getstatic run // 线程 t 获取 run true getstatic run // 线程 t 获取 run true getstatic run // 线程 t 获取 run true getstatic run // 线程 t 获取 run true putstatic run // 线程 main 修改 run 为 false，仅此一次 getstatic run // 线程 t 获取 run false

比较一下之前我们将线程安全时举的例子：两个线程一个 i++ 一个 i-- ，只能保证看到最新值，不能解决指令交错。

即读取值,操作值，写入值，这三步是一个原子性的操作，必须放在一起执行，要么全部成功要么全部失败。

synchronized 语句块既可以保证代码块的原子性，也同时保证代码块内变量的可见性。

但缺点是synchronized 是属于重量级操作，性能相对更低

// 假设i的初始值为0 getstatic i // 线程2-获取静态变量i的值线程内i=0 getstatic i // 线程1-获取静态变量i的值线程内i=0 iconst_1 // 线程1-准备常量1 iadd // 线程1-自增线程内i=1 putstatic i // 线程1-将修改后的值存入静态变量i 静态变量i=1 iconst_1 // 线程2-准备常量1 isub // 线程2-自减线程内i=-1 putstatic i // 线程2-将修改后的值存入静态变量i 静态变量i=-1

synchronized可见性

JMM关于synchronized的两条可见性规定:

-线程解锁前,必须把共享变量的最新值刷新到主内存中

-线程加锁时,将清空工作内存中共享变量的值,从而使用共享变量时需要从主内存中重新读取最新的值

synchronized 语句块既可以保证代码块的原子性，也同时保证代码块内变量的可见性。

但缺点是synchronized 是属于重量级操作，性能相对更低。

如果在前面示例的死循环中加入 System.out.println("stop")会发现即使不加 volatile 修饰符，线程 t 也能正确看到对 run 变量的修改了，想一想为什么？

因为System.out.println()里面是一个synchronize方法。

在synchronize解锁前，把共享变量run的最新值刷新到主内存中。

虽然synchronize在PrintStream中，但是run变量属于当前线程,PrintStream也属于当前线程。

5.3 有序性

JVM 会在不影响正确性的前提下，可以调整语句的执行顺序，即as-if-serial语义思考下面一段代码

static int i; static int j; // 在某个线程内执行如下赋值操作 i = ...; j = ...;

可以看到，至于是先执行 i 还是先执行 j ，对最终的结果不会产生影响。所以，上面代码真正执行时，既可以是

i = ...; j = ...; 也可以是 j = ...; i = ...;

这种特性称之为『指令重排』，多线程下『指令重排』会影响正确性。为什么要有重排指令这项优化呢？从 CPU执行指令的原理来理解一下吧

诡异的结果

int num = 0; boolean ready = false; // 线程1 执行此方法 public void actor1(I_Result r) { if(ready) { r.r1 = num + num; } else { r.r1 = 1; } } // 线程2 执行此方法 public void actor2(I_Result r) { num = 2; ready = true; } //I_Result 是一个对象，有一个属性 r1 用来保存结果，r1和ready的可能的结果有几种？

情况1：线程1 先执行，这时 ready = false，所以进入 else 分支结果为ready = false,r1=1

情况2：线程2 先执行 num = 2，但没来得及执行 ready = true，线程1 执行，还是进入 else 分支，结果为ready = false,r1=1

情况3：线程2 执行到 ready = true，线程1 执行，这回进入 if 分支，结果为 4(因为 num 已经执行过了)ready = true,r1=4

指令重排

但我告诉你，结果还有可能是 0，信不信吧！这种情况下是：线程2 先执行 ready = true，切换到线程1，进入 if 分支，相加为 0，再切回线程2 执行 num = 2，结果ready = true,r1=0

这种现象叫做指令重排，是 JIT 编译器在运行时的一些优化，即生成的机器指令与字节码指令顺序不一致(java层面)。这个现象需要通过大量测试才能复现！

指令重排序

指的是JIT编译器、cpu处理器和jmm定义的多级缓存存储，在编译字节码和运行机器指令时，在不影响程序最终执行结果的情况下，会对原语句执行的顺序进行优化。

jmm多级缓存会让语句的执行并不一定是按照正确的读写操作进行的。

但是这些都是jmm所允许的操作。

因此需要通过同步来禁止相关的指令重排序，如内存屏障。

指令级并行原理

1. 名词

Clock Cycle Time

主频的概念大家接触的比较多，而 CPU 的 Clock Cycle Time(时钟周期时间)，等于主频的倒数。意思是 CPU 能够识别的最小时间单位，比如说 4G 主频的 CPU 的 Clock Cycle Time 就是 0.25 ns，作为对比，我们墙上挂钟的 Cycle Time 是 1s 。

例如，运行一条加法指令一般需要一个时钟周期时间

CPI

有的指令需要更多的时钟周期时间，所以引出了 CPI (Cycles Per Instruction)指令平均时钟周期数

IPC

IPC(Instruction Per Clock Cycle) 即 CPI 的倒数，表示每个时钟周期能够运行的指令数

CPU 执行时间

程序的 CPU 执行时间，即我们前面提到的 user + system 时间，可以用下面的公式来表示

程序 CPU 执行时间 = 指令数 * CPI * Clock Cycle Time

2. 鱼罐头的故事

加工一条鱼需要 50 分钟，只能一条鱼、一条鱼顺序加工

可以将每个鱼罐头的加工流程细分为 5 个步骤：

去鳞清洗 10分钟

蒸煮沥水 10分钟

加注汤料 10分钟

杀菌出锅 10分钟

真空封罐 10分钟

即使只有一个工人，最理想的情况是：他能够在 10 分钟内同时做好这 5 件事，因为对第一条鱼的真空装罐，不会影响对第二条鱼的杀菌出锅

3.指令重排序优化

事实上，现代处理器会设计为一个时钟周期完成一条执行时间最长的 CPU 指令。为什么这么做呢？

可以想到指令还可以再划分成一个个更小的阶段，例如，每条指令都可以分为：取指令 - 指令译码 - 执行指令 - 内存访问 - 数据写回这 5 个阶段。

在不改变程序结果的前提下，这些指令的各个阶段可以通过重排序和组合来实现指令级并行，这一技术在 80's 中叶到 90's 中叶占据了计算架构的重要地位。分阶段，分工是提升效率的关键！

指令重排的前提是，重排指令不能影响结果，例如

// 可以重排的例子 int a = 10; // 指令1 int b = 20; // 指令2 System.out.println( a + b ); // 不能重排的例子 int a = 10; // 指令1 int b = a - 5; // 指令2

4.支持流水线的处理器

现代 CPU 支持多级指令流水线，例如支持同时执行取指令 - 指令译码 - 执行指令 - 内存访问 - 数据写回的处理器，就可以称之为五级指令流水线。

这时 CPU 可以在一个时钟周期内，同时运行五条指令的不同阶段(相当于一条执行时间最长的复杂指令)，IPC = 1，本质上，流水线技术并不能缩短单条指令的执行时间，但它变相地提高了指令地吞吐率。

从cpu层面理解上面的诡异结果：指令并行会将条指令的不同阶段批量并发执行。

从cpu层面可以理解为: 把num = 2分为5个阶段把ready = true分为5个阶段。那么如果ready先执行完，就会出现上面

的问题。

5.解决方法:禁止指令重排序:volatile

volatile 修饰的变量，可以禁用指令重排

6.volatile原理:内存屏障读前写后

volatile 的底层实现原理是内存屏障

-对 volatile 变量的读指令前会加入读屏障

-对 volatile 变量的写指令后会加入写屏障

为了提高处理速度，处理器不直接和内存进行通信，而是先将系统内存的数据读到内部缓存(L1，L2或其他)后再进行操作，但操作完不知道何时会写到内存。

如果对声明volatile的变量进行写操作，JVM就会向处理器发送一条Lock前缀的指令，将这个变量所在缓存行的数据写回到系统内存。但是，就算写回到内存，如果其他处理器缓存的值还是旧的，再执行计算操作就会有问题。

所以，在多处理器下，为了保证各个处理器的缓存是一致的，就会实现缓存一致性协议，每个处理器通过嗅探在总线上传播的数据来检查自己缓存的值是不是过期了，当处理器发现自己缓存行对应的内存地址被修改，就会将当前处理器的缓存行设置成无效状态，当处理器对这个数据进行操作的时候，会重新从系统内存中把数据读到处理器缓存里。

下面来具体讲解volatile的两条实现原则。

1)Lock前缀指令会引起处理器缓存回写到内存

2)一个处理器的缓存回写到内存会导致其他处理器的缓存无效

volatile实现原理

volatile 的底层实现原理是内存屏障，Memory Barrier(Memory Fence)

-对 volatile 变量的写指令后会加入写屏障 -对 volatile 变量的读指令前会加入读屏障

volatile变量执行写操作

volatile变量执行写操作，会在写之前插入StoreStore Barriers，在写之后插入StoreLoad Barriers。

volatile变量在执行写操作之前插入StoreStore Barriers，代表在执行volatile变量写之前的所有Store操作都已执行，

数据同步到了内存中(将store buffer中的store操作刷新到内存即将volatile变量之前的写操作都同步到内存)；

写之后插入StoreLoad Barriers，代表volatile变量的写操作也会立即刷新到内存中，其他线程会看到最新值。

volatile变量执行读操作

volatile变量执行读操作，会在读之前插入LoadLoad Barriers，在读之后插入LoadStore Barriers。

volatile变量在执行读操作之前插入LoadLoad Barriers，代表在执行volatile变量读之前的所有Load从内存中获取最新

值；在读之后插入LoadStore Barriers，代表该读取volatile变量获得是内存中最新的值。

看下面这道思考题，选择使用volatile变量修饰其中一个变量，满足当cpu2判断flag为true成立时，number的值一定为1：

``` //初始 number=0, flag=false

// cpu1

int number = 1;

int flag = true;

// cpu2

if(flag){ print(number); } ```

答案是：用volatile修饰变量flag。因为cpu1会在执行flag = true之前插入StoreStore Barriers，所以number = 1一定会先执行，并将number的数据刷新到内存中，然后再执行flag = true；cpu2判断flag为true成立时，number的值一定为1。

假设不用volatile修饰变量flag，cpu1可能会重排序，flag = true会先执行；然后cpu2判断flag为true，直接输出number的值，这时还未执行number = 1，输出number的值为0。

1.如何保证可见性

写屏障

写屏障(sfence)保证在该屏障之前对共享变量的改动，都同步到主存当中

写屏障会确保指令重排序时，不会将写屏障之前的代码排在写屏障之后。

public void actor2(I_Result r) { num = 2; ready = true; // ready 是 volatile 修饰,带写屏障 //写屏障,保证在该屏障之前的，对共享变量的改动，都同步到主存当中。 //对ready做了修改以后,主存中的数据就是最新的数据。 //也就相当于对共享变量的读取，加载的是主存中最新数据 }

读屏障

而读屏障(lfence)保证在该屏障之后，对共享变量的读取，加载的是主存中最新数据

public void actor1(I_Result r) { // 读屏障 // ready 是 volatile 读取值带读屏障 if(ready) { r.r1 = num + num; } else { r.r1 = 1; } }

2.如何保证有序性

写屏障

写屏障会确保指令重排序时，不会将写屏障之前的代码排在写屏障之后

读屏障

读屏障会确保指令重排序时，不会将读屏障之后的代码排在读屏障之前

3.不能解决多线程下指令交错

写屏障仅仅是保证之后的读能够读到最新的结果，但不能保证读跑到它前面去而有序性的保证也只是保证了本线程内相关代码不被重排序。

具体参考该公众号文档并抽时间整理

5.volatile是什么？怎么保证可见性？ (qq.com)

happens-before原则-禁止编译优化

--如果操作1 happens-before 操作2，那么操作1的执行结果将对操作2可见，而且操作1的执行顺序排在第操作2之前。

--两个操作之间存在happens-before关系，并不意味着一定要按照happens-before原则制定的顺序来执行。

如果重排序之后的执行结果与按照happens-before关系来执行的结果一致，那么这种重排序并不非法

上面的1)是JMM对程序员的承诺。从程序员的角度来说，可以这样理解happens-before关系：如果A happens-before B，那么Java内存模型将向程序员保证——A操作的结果将对B可见，且A的执行顺序排在B之前。

注意，这只是Java内存模型向程序员做出的保证！

上面的2)是JMM对编译器和处理器重排序的约束原则。正如前面所言，JMM其实是在遵循一个基本原则：只要不改变程序的执行结果(指的是单线程程序和正确同步的多线程程序)，编译器和处理器怎么优化都行。

JMM这么做的原因是：程序员对于这两个操作是否真的被重排序并不关心，程序员关心的是程序执行时的语义不能被改变(即执行结果不能被改变)。因此，happens-before关系本质上和as-if-serial语义是一回事。

为什么会有happens-before 规则？

我们知道cpu的运行极快，而读取主存对于cpu而言有点慢了，在读取主存的过程中cpu一直闲着(也没数据可以运行)，这对资源来说造成极大的浪费。所以慢慢的cpu演变成了多级cache结构，cpu在读cache的速度比读内存快了n倍。

当线程在执行时，会保存临界资源的副本到私有work memory中，这个memory在cache中，修改这个临界资源会更新work memory但并不一定立刻刷到主存中，那么什么时候应该刷到主存中呢？什么时候和其他副本同步？

而且编译器为了提高指令执行效率，是可以对指令重排序的，重排序后指令的执行顺序不一样，有可能线程2读取某个变量时，线程1还未进行写入操作。这就是线程可见性的来源。

针对以上两个问题，JMM给出happens-before通用的规则

因为jvm会对代码进行编译优化，指令会出现重排序的情况，为了避免编译优化对并发编程安全性的影响，需要

happens-before规则定义一些禁止编译优化的场景，保证并发编程的正确性。

happens-before 规定了对共享变量的写操作对其它线程的读操作可见，它是可见性与有序性的一套规则总结。

抛开以下 happens-before 规则。JMM 并不能保证一个线程对共享变量的写，对于其它线程对该共享变量的读可见。

1.程序次序规则

同一个线程内，书写在前面的操作先行发生于书写在后面的操作：在一个单独的线程中，按照程序代码的执行流顺序，(时间上)先执行的操作happen—before(时间上)后执行的操作,同一个线程中前面的所有写操作对后面的操作可见。

存在依赖关系，不会指令重排序

int a = 3; //代码1 赋值操作 int b = a + 1; //代码2 赋值操作

上面的代码中，因为代码2的计算会用到代码1的运行结果，此时程序次序规则就会保证代码2中的a一定为3，不会是0(默认初始化的值)，所以JVM不允许操作系统对代码1、2进行重排序，即代码1一定在代码2之前执行。下面的例子就无法保证执行顺序：

int a = 3; //代码1 读取操作 int b = 2; //代码2 读取操作

上面的代码中，代码1、2之间没有依赖关系，所以指令重排序有可能会发生，b的初始化可能比a早。

2.管程锁定规则

一个unLock操作先行发生于后面对同一个锁的lock操作:线程解锁 m 之前对变量的写(保证写入主存)，对于接下来对 m 加锁的其它线程对该变量的读可见(保证读取最新)。

解锁先于加锁

也可以理解为必须先解锁才能再加锁。

static int x; static Object m = new Object(); new Thread(()->{ synchronized(m) { x = 10; } },"t1").start(); new Thread(()->{ synchronized(m) { System.out.println(x); } },"t2").start(); 输出:10 即如果线程1先执行，线程2再执行,t1线程解锁之前对变量x的操作,对接下来使用m加锁的线程t2可见

3.volatile变量规则

线程对 volatile 变量的写，对接下来其它线程对该变量的读可见。

volatile变量的可见性

可以理解为必须等写线程执行完毕,后续的读线程才能读。即如果还没写完就不能读。

volatile static int x; new Thread(()->{ x = 10; },"t1").start(); new Thread(()->{ System.out.println(x); },"t2").start(); 如果线程1先执行，线程2再执行，则volatile变量规则可以保证线程2输出:10

4.线程启动规则

Thread对象的start()方法先行发生于此线程的每个一个动作；比如start以后才能sleep

线程 start 前对变量的写，在该线程 start后,该变量对该线程的读可见

static int x; x = 10; new Thread(()->{ System.out.println(x); },"t2").start(); 输出:10

5.线程终结规则

线程中所有的操作都先行发生于线程的终止检测，我们可以通过Thread.join()方法结束、Thread.isAlive()的返回值手段检测到线程已经终止执行。也就是说一个线程的开启、睡眠、等待、肯定是发生于Thread.join()等方法。

线程结束前对变量的写，对其它线程得知它结束后的读可见(比如其它线程调用 t1.isAlive() 或 t1.join()等待它结束)

static int x; Thread t1 = new Thread(()->{ x = 10; },"t1"); t1.start(); t1.join(); System.out.println(x);

6.线程中断规则

对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生。

即必须是先调用interrupt(),后面才能检测到中断事件的发生。

线程t1写入的所有变量，调用t2.interrupt()打断线程t2，可以看到t1的全部操作

java interrupt()方法只是设置线程的中断标记，当对处于阻塞状态的线程调用interrupt方法时(处于阻塞状态的线程是调用sleep, wait, join 的线程)，会抛出InterruptException异常，而这个异常会清除中断标记。

static int x; public static void main(String[] args) { Thread t2 = new Thread(()->{ while(true) { if(Thread.currentThread().isInterrupted()) { System.out.println(x); break; } } },"t2"); t2.start(); new Thread(()->{ sleep(1); x = 10; t2.interrupt(); },"t1").start(); while(!t2.isInterrupted()) { Thread.yield(); } System.out.println(x); } 输出:10

7.对象终结规则

一个对象的初始化完成(构造函数执行结束)happen—before它的finalize()方法的开始。 (对象调用finalize()方法时，对象初始化完成的任意操作，同步到全部主存同步到全部cache。)

8.传递性

如果操作A happen—before操作B，操作B happen—before操作C，那么可以得出A happen—before操作C。(A h-b B ， B h-b C 那么可以得到 A h-b C)似数学的传递性：A>B,B>C则A>C.

volatile int var; int b; int c; //线程1执行内容 public void method1() { b = 4; //1 var = 3; //2 } //线程2执行内容 public void method2() { c = var; //3 c = b; //4 }

假设执行顺序为 1、2、3、4，由于单线程的程序次序规则，得出1 Happen Before 2，3 Happen Before 4，又因为volatile变量规则得出2 Happen Before 3，所以1 Happen Before 3，1 Happen Before 4(传递性)，即最后变量c的值为4；若执行顺序为1、3、4、2，因为3、2没有匹配到Happen Before规则，所以无法通过传递性推测出传递关系，也就无法保证最后变量c的值为4，也可能为0(b初始化的值，没有读到线程1写入的值)

线程启动规则、线程终结规则、线程中断规则、对象终结规则四个规则相对比较易于理解，不再赘述。

https://www.jianshu.com/p/b9186dbebe8e

https://www.jianshu.com/p/8c6efbb80e5d

然而,然而

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
7.java并发编程之volatile与happends before

JMM共享模型之内存5.1 Java 内存模型JMM 即 Java Memory Model。它定义了主存、工作内存抽象概念，底层对应着 CPU 寄存器、缓存、硬件内存、CPU 指令优化等。JMM 体现在以下几个方面:原子性 - 保证指令不会受到线程上下文切换的影响可见性 - 保证指令不会受 cpu 缓存的影响有序性 - 保证指令不会受 cpu 指令并行优化的影响5...
复制链接

扫一扫