目录
前提说明
JMM开始
JMM有以下规定
JMM的8种操作
MESI(缓存一致性协议)
JMM对这八种指令的使用,制定了如下规则
Volatile的可见性实现原理
指令重排和内存屏障
Volatile内存语义的实现
volatile与synchronized的区别
总结
线程在堆中的私有空间
Volatile在AQS中的大量使用
Synchronized的基本原理
本次文章中涉及到的三个知识点会在后面的文章依次介绍并附上链接地址
JMM内存模型(Java内存模型)跟cpu内存模型类似,是基于cpu缓存模型来建立的,Java线程内存模型是标准化的,屏蔽掉了底层不同计算机的区别
描述了Java程序中各种变量(线程共享变量)的访问规则,以及在JVM中将变量,存储到内存和从内存中读取变量这样的底层细节。
结构图:
所有的共享变量都存储于主内存,这里所说的变量指的是实例变量和类变量,不包含局部变量,因为局部变量是线程私有的,因此不存在竞争问题。
每一个线程还存在自己的工作内存,线程的工作内存,保留了被线程使用的变量的工作副本(这一部分在JVM里面会有详细的介绍)。
线程对变量的所有的操作(读,取)都必须在工作内存中完成,而不能直接读写主内存中的变量。
不同线程之间也不能直接访问对方工作内存中的变量,线程间变量的值的传递需要通过主内存中转来完成。
线程解锁前,必须把共享变量立刻刷新会主存
线程加锁前,必须读取主存中的最新值到自己线程的工作内存中
加锁和解锁是同一把锁
作用于主内存的变量,把一个变量标识为线程独占状态
作用于主内存的变量,它把一个处于锁定状态的变量释放出来,释放后的变量才可以被其他线程锁定
作用于主内存变量,它把一个变量的值从主内存传输到线程的工作内存中,以便随后的load动作使用
作用于工作内存的变量,它把read操作从主存中变量放入工作内存中
作用于工作内存中的变量,它把工作内存中的变量传输给执行引擎,每当虚拟机遇到一个需要使用到变量的值,就会使用到这个指令
作用于工作内存中的变量,它把一个从执行引擎中接受到的值(计算好的值)放入工作内存的变量副本中
作用于主内存中的变量,它把一个从工作内存中一个变量的值传送到主内存中,以便后续的write使用
作用于主内存中的变量,它把store操作从工作内存中得到的变量的值放入主内存的变量中
多个cpu从主内存中读取到同一个数据到各自的高速缓存,当其中某个cpu修改了缓存里面的数据,该数据会马上同步回主内存,其他cpu通过总线嗅探机制可以感知到数据的变化从而将自己缓存里的数据失效.(再次需要从主内存中取出来最新的数据) 对于直接对总线加锁(cpu从主内存中读取数据到高速缓存中,会在总线对这个数据加锁,这样其他Cpu没法去读或者写这个数据,直到这个cpu使用完数据释放锁之后其他cpu才能读取该数据;read之前会先lock把一个变量标识为线程独占状态 )的粒度大大变小
如何发现数据是否失效????--------嗅探
每个处理器通过嗅探在总线上传播的数据来检查自己缓存的值是不是过期了,当处理器发现自己缓存行对应的内存地址被修改,就会将当前处理器的缓存行设置成无效状态,当处理器对这个数据进行修改操作的时候,会重新从系统内存中把数据读到处理器缓存里。
1,不允许read和load、store和write操作之一单独出现。即使用了read必须load,使用了store必须write
2,不允许线程丢弃他最近的assign操作,即工作变量的数据改变了之后,必须告知主存
3,不允许一个线程将没有assign的数据从工作内存同步回主内存
4,一个新的变量必须在主内存中诞生,不允许工作内存直接使用一个未被初始化的变量。就是怼变量实施use、store操作之前,必须经过assign和load操作
5,一个变量同一时间只有一个线程能对其进行lock。多次lock后,必须执行相同次数的unlock才能解锁
6,如果对一个变量进行lock操作,会清空所有工作内存中此变量的值,在执行引擎使用这个变量前,必须重新load或assign操作初始化变量的值
7,如果一个变量没有被lock,就不能对其进行unlock操作。也不能unlock一个被其他线程锁住的变量
8,对一个变量进行unlock操作之前,必须把此变量同步回主内存
底层实现主要是通过汇编lock前缀指令,他会锁定这块内存区域的缓存(缓存行锁定)并回写到内存
为什么要加锁???为了防止误读 监听到变量发生变化到主内存中去取但是此时还未将真正的变量值写回
A-32架构软件开发者手册对Lock指令的解释
并发编程的三大特性: 可见性 原子性 有序性
Volatile保证可见性与有序性,但是不保证原子性,保证原子性需要借助synchronized这样的锁机制
什么是指令重排????
指令重排序:在不影响单线程程序执行结果的前提下,计算机为了最大程度的发挥机器的性能,会对机器指令排序优化
重排序会遵循as-if-serial和happens-before原则
as-if-serial:不管怎么排序,单线程程序的执行结果不能被改变.编译器,runtime和处理器都必须遵守as-if-serial
为了遵守as-if-serial语义,编译器和处理器不会对单线程中存在数据依赖关系的操作做重排序,因为这种重排序会改变执行结果,但是如果操作之间不存在数据以来的关系,这些操作就可能被编译器和处理器重排序
happens-before:只靠synchronized和volatile关键字来保证原子性,可见性和有序性,编写并发程序会显得十分麻烦,幸运的是,从JDK5开始,Java使用新的JSR-133内存模型,提供了happens-before原则来辅助保证程序执行的原子性,可见性和有序性的问题,他是判断数据是否存在竞争,线程是否安全的依据
条件2中
lock -> unlock -> lock -> unlock
lock -> lock -> unlock -> unlock(不符合语义,变成了重入锁)
既然要经历指令重排,那么volatile是如何保证有序性(禁止指令重排序 )的呢????
这就不得不提到内存屏障
屏障类型 | 指令示例 | 说明 |
---|---|---|
LoadLoad | Load1;LoadLoad;Load2 | 保证load1的读取操作在load2及后续读取操作之前执行 |
StoreStore | Store1;StoreStore;Store2 | 在store2及其后的写操作之前,保证store1的写操作已刷新到主内存 |
LoadStore | Load1;LoadStore;Store2 | 在store2及其后的写操作之前,保证Load1的读操作2已读取结束 |
StoreLoad | Store1;StoreLoad;Load2 | 保证store1的写操作已刷新到主内存中之hi偶,Load2及其后的读取操作才能执行 |
解释:因为a是volatile修饰的变量,在a=1写操作之前必须要保证a=2的写操作已刷新到主内存;
b=a是一个取值操作,必须要保证保证a=1的写操作已刷新到主内存中之后,b=a的读取操作才能执行
内存屏障,又称内存栅栏,是一个CPU指令,它的作用有两个,一是保证特性操作的执行顺序,二是保证某些变量的内存可见性,.由于编译器和处理器都能执行指令重排优化,如果在指令间插入一条Memory Barrier则会告诉编译器和CPU,不管什么指令都不能和这条Memory Barrier指令重排序,也就是说通过插入内存屏障禁止在内存屏障前后的指令执行重排序优化.Memory Barrier的另外一个作用是强制刷出各种CPU的缓存数据,因此任何CPU上的线程都能读取到这些数据最新版本;总之volatile变量是通过内存屏障实现其在内存中的语义,即可见性和禁止重拍优化,下面看一个非常典型的禁止重排的DCL锁,
java代码:
反编译后截取的部分指令(这部分会在JVM里面详细介绍):
前面提到过重排序分为编译器重排序和处理器重排序,为了实现volatile内存语义,JMM会分别限制这两种类型的重排序类型,下图是JMM针对编译器制定的volatile重排序规则表
第一个操作 | 第二个操作:普通读写 | 第二个操作:volatile读 | 第二个操作:volatile写 |
---|---|---|---|
普通读写 | 可以重排 | 可以重排 | 不可以重排 |
volatile读 | 不可以重排 | 不可以重排 | 不可以重排 |
volatile写 | 可以重排 | 不可以重排 | 不可以重排 |
举例来说,第二行最后一个单元格的意思是:在程序中,当第一个操作为普通变量的读或者写时,如果第二个操作为volatile写,则编译器不能重排序这两个操作
图形化展示:
写:
读:
从上图可以看出
当第二个操作为volatile写时,不管第一个操作是什么,都不能重排序,这个规则确保volatile写之前的操作不会被编译器重排序到volatile写之后.
当第一个操作是volatile读时,不管第二个操作是什么,都不能重排序,这个规则确保volatile读之后的操作不会被编译器重排序到volatile读之前.
当第一个操作是volatile写时,不管第二个操作是volatile读或者写时,不能重排序.
为了实现volatile的内存语义,编译器在生成字节码时,会在指令序列中插入内存屏障来禁止特定类型的处理器重排序,对于编译器来说,发现一个最优布置来最小化插入屏障的总数几乎不可能,为此,JMM采取保守策略,下面是基于操守策略JMM内存屏障插入策略
在每个Volatile写操作的前面插入一个StoreStore屏障
在每个Volatile写操作的后面插入一个StoreLoad屏障
在每个Volatile读操作的前面插入一个LoadLoad屏障
在每个Volatile读操作的后面插入一个LoadStore屏障
上述内存屏障插入策略非常保守,但他可以保证在任意处理器平台,任意的程序中都能得到正确的volatile内存语义
Demo:
在并发场景下,i变量的任何改变都会立马反应到其他线程中,但是如此存在多条线程同时调用increase()方法的话,就会出现线程安全毕竟k++操作不具备原子性,该操作实现读取值然后写回一个新值,相当于原来的值加上1,分两步完成.如果第二个线程在第一个线程读取旧值和写回新值期间读取i的域值,那么第二个线程就会与第一个线程一起看到同一个值,并执行相同值的加1操作,这也造成了线程安全失败,因此对于increase方法必须使用synchronized修饰,以便保证线程安全,需要注意的是一但使用synchronized修饰方法后,由于synchronized本身也具有和volatile相同的特性,即可见性,因此在这样的情况下可以省去volatile修饰变量
为啥加锁可以解决可见性问题呢???? 因为某一个线程进入synchronized代码块前后,线程会获得锁,清空工作内存,从主内存拷贝共享变量最新的值到工作内存成为副本,执行代码,将修改后的副本的值刷新回主内存中,线程释放锁。
上面提到了volatile与synchronized,聊一下他们的区别。
synchronized详细解释会在下一章节详细解释
volatile只能修饰实例变量和类变量,而synchronized可以修饰方法,以及代码块。
volatile保证数据的可见性,但是不保证原子性(多线程进行写操作,不保证线程安全);而synchronized是一种排他(互斥)的机制。 volatile用于禁止指令重排序:可以解决单例双重检查对象初始化代码执行乱序问题。
volatile可以看做是轻量版的synchronized,volatile不保证原子性,但是如果是对一个共享变量进行多个线程的赋值,而没有其他的操作,那么就可以用volatile来代替synchronized,因为赋值本身是有原子性的,而volatile又保证了可见性,所以就可以保证线程安全了。
volatile修饰符适用于以下场景:
关于Volatile的使用,在AQS会有大量的使用,在AQS有关的文章中会详细介绍