谈谈Volatile
JUC简介
- JUC(java.util.concurrent)
- 进程和线程
- 进程:后台运行的程序(我们打开的一个软件,就是进程)
- 线程:轻量级的进程,并且一个进程包含多个线程(同在一个软件内,同时运行窗口,就是线程)
- 并发和并行
- 并发:同时访问某个东西,就是并发
- 并行:一起做某些事情,就是并行
- 进程和线程
- JUC下的三个包
- java.util.concurrent
- java.util.concurrent.atomic
- java.util.concurrent.locks
- java.util.concurrent
谈谈对Volatile的理解
Volatile在日常的单线程环境是应用不到的
- 🤔 Volatile是Java虚拟机提供的
轻量级
的同步机制(三大特性)- 保证可见性
- 不保证原子性
- 禁止指令重排
JMM概述
JMM是Java内存模型,也就是Java Memory Model,简称JMM,本身是一种抽象的概念,实际上并不存在,它描述的是一组规则或规范,通过这组规范定义了程序中各个变量(包括实例字段,静态字段和构成数组对象的元素)的访问方式
JMM关于同步的规定:
- 线程解锁前,必须把共享变量的值刷新回主内存
- 线程解锁前,必须读取主内存的最新值,到自己的工作内存
- 加锁和解锁是同一把锁
由于JVM运行程序的实体是线程,而每个线程创建时JVM都会为其创建一个工作内存(有些地方称为栈空间),工作内存是每个线程的私有数据区域,而Java内存模型中规定所有变量都存储在主内存,主内存是共享内存区域,所有线程都可以访问,但线程对变量的操作(读取赋值等)必须在工作内存中进行,首先要将变量从主内存拷贝到自己的工作内存空间,然后对变量进行操作,操作完成后再将变量写会主内存,不能直接操作主内存中的变量,各个线程中的工作内存中存储着主内存中的变量副本拷贝,因此不同的线程间无法访问对方的工作内存,线程间的通信(传值)必须通过主内存来完成,其简要访问过程:
数据传输速率:硬盘 < 内存 < < cache < CPU
上面提到了两个概念:主内存 和 工作内存
-
主内存:就是计算机的内存,也就是经常提到的8G内存,16G内存
-
工作内存:但我们实例化 new student,那么 age = 25 也是存储在主内存中
- 当同时有三个线程同时访问 student中的age变量时,那么每个线程都会拷贝一份,到各自的工作内存,从而实现了变量的拷贝
即:JMM内存模型的可见性,指的是当主内存区域中的值被某个线程写入更改后,其它线程会马上知晓更改后的值,并重新得到更改后的值。
JMM的特性
🤔 JMM的三大特性,volatile只保证了两个,即可见性和有序性,不满足原子性
- 可见性
- 原子性
- 有序性
可见型
各个线程对主内存中共享变量的操作都是各个线程各自拷贝到自己的工作内存进行操作后再写回到主内存中的。
这就可能存在一个线程AAA修改了共享变量X的值但还未写回主内存时,另外一个线程BBB又对主内存中。同一个共享变量X进行操作,但此时A线程工作内存中共享变量x对线程B来说并不可见,这种工作内存与主内存同步延迟现象就造成了可见性问题。
可见性代码验证
但我们对于成员变量没有添加任何修饰时,是无法感知其它线程修改后的值
package com.moxi.interview.study.thread;
/**
* Volatile Java虚拟机提供的轻量级同步机制
*
* 可见性(及时通知)
* 不保证原子性
* 禁止指令重排
*/
import java.util.concurrent.TimeUnit;
/**
* 假设是主物理内存
*/
class MyData {
int number = 0;
public void addTo60() {
this.number = 60;
}
}
/**
* 验证volatile的可见性
* 1. 假设int number = 0, number变量之前没有添加volatile关键字修饰
*/
public class VolatileDemo {
public static void main(String args []) {
// 资源类
MyData myData = new MyData();
// AAA线程 实现了Runnable接口的,lambda表达式
new Thread(() -> {
System.out.println(Thread.currentThread().getName() + "\t come in");
// 线程睡眠3秒,假设在进行运算
try {
TimeUnit.SECONDS.sleep(3);
} catch (InterruptedException e) {
e.printStackTrace();
}
// 修改number的值
myData.addTo60();
// 输出修改后的值
System.out.println(Thread.currentThread().getName() + "\t update number value:" + myData.number);
}, "AAA").start();
while(myData.number == 0) {
// main线程就一直在这里等待循环,直到number的值不等于零
}
// 按道理这个值是不可能打印出来的,因为主线程运行的时候,number的值为0,所以一直在循环
// 如果能输出这句话,说明AAA线程在睡眠3秒后,更新的number的值,重新写入到主内存,并被main线程感知到了
System.out.println(Thread.currentThread().getName() + "\t mission is over");
/**
* 最后输出结果:
* AAA come in
* AAA update number value:60
* 最后线程没有停止,并行没有输出 mission is over 这句话,说明没有用volatile修饰的变量,是没有可见性
*/
}
}
输出结果为
最后线程没有停止,并行没有输出 mission is over 这句话,说明没有用volatile修饰的变量,是没有可见性
当我们修改MyData类中的成员变量时,并且添加volatile关键字修饰
/**
* 假设是主物理内存
*/
class MyData {
/**
* volatile 修饰的关键字,是为了增加 主线程和线程之间的可见性,只要有一个线程修改了内存中的值,其它线程也能马上感知
*/
volatile int number = 0;
public void addTo60() {
this.number = 60;
}
}
最后输出的结果为:
主线程也执行完毕了,说明volatile修饰的变量,是具备JVM轻量级同步机制的,能够感知其它线程的修改后的值。
原子性
不可分割,完整性,也即某个线程正在做某个具体业务时,中间不可以被加塞或者被分割。需要整体完整要么同时成功,要么同时失败。
volatile不保存原子性代码验证
class MyData2 {
// 注意!😈
volatile int number = 0;
// ❕ 此时number前面是加了volatile关键字修饰的,不保证原子性
public void addPlusPlus() {
number++;
}
}
public class VolatileDemo2 {
public static void main(String args[]) {
MyData2 myData2 = new MyData2();
for (int i = 0; i < 20; i++) {
new Thread(() -> {
// method
for (int j = 0; j < 2000; j++) {
myData2.addPlusPlus();
}
}, String.valueOf(i)).start();
}
// 需要等待上面20个线程都全部计算完成后,再main线程取得最终的结果值看是多少?
while(Thread.activeCount()>2){ // 默认后台有main线程和gc线程
// 使当前线程由执行状态,变成为就绪状态,让出cpu时间,在下一个线程执行时候,此线程有可能被执行,也有可能没有被执行
Thread.yield();
}
System.out.println(Thread.currentThread().getName()+"\t finally number value: "+myData2.number);
}
}
为什么
在执行putfield
写命令的时候,当前线程可能被挂起,此时在线程的工作区已经完成了iadd
操作,唤醒时会造成写覆盖。
如何解决原子性
- 在方法上加sync(太重量级)
- 使用原子类
AtomicInteger
,⚠️:原子类自带volatileprivate volatile int value;
// 在可见性的基础上增加原子性
class MyData3 {
// 注意!😈
AtomicInteger atomicInteger = new AtomicInteger();
// ❕ 此时number前面是加了volatile关键字修饰的,不保证原子性
public void addPlusPlus() {
atomicInteger.getAndIncrement();
}
}
public class VolatileDemo3 {
public static void main(String args[]) {
MyData3 myData = new MyData3();
for (int i = 0; i < 20; i++) {
new Thread(() -> {
// method
for (int j = 0; j < 2000; j++) {
myData.addPlusPlus();
}
}, String.valueOf(i)).start();
}
// 需要等待上面20个线程都全部计算完成后,再main线程取得最终的结果值看是多少?
while(Thread.activeCount()>2){ // 默认后台有main线程和gc线程
// 使当前线程由执行状态,变成为就绪状态,让出cpu时间,在下一个线程执行时候,此线程有可能被执行,也有可能没有被执行
Thread.yield();
}
System.out.println(Thread.currentThread().getName()+"\t finally number value: "+myData.atomicInteger);
}
}
有序性
计算机在执行程序时,为了提高性能,编译器和处理器的常常会对指令做重排,一般分以下3种:
**单线程环境**里面确保程序最终执行结果和代码顺序执行的结果一致(也会出现重排序,但不会影响结果)。
处理器在进行重排序时必须要考虑指令之间的**数据依赖性**
多线程环境中线程交替执行,由于编译器优化重排的存在,两个线程中使用的变量能否保证一致性是无法确定的,结果无法预测。
重排案例1
public void mySort(){
int x = 11; //语句1
int y = 12; //语句2
x = x + 5; //语句3
y = x * x; //语句4
}
多线程情况下可能重新排列为1234/2134/1324
语句4可以重排后变成第一个吗?:不可以🙅,处理器在进行重排序时必须要考虑指令之间的**数据依赖性**。
重排案例2
重排案例3
禁止指令重排小总结
volatile实现禁止指令重排优化,从而避免多线程环境下程序出现乱序执行的现象。
先了解一个概念,内存屏障(Memory Barrier)又称内存栅栏,是一个CPU指令,它的作用有两个:
- 保证特定操作的执行顺序
- 保证某些变量的内存可见性(利用该特性实现volatile的内存可见性)
由于编译器和处理器都能执行指令重排优化。如果在指令间插入一条MemoryBarrier则会告诉编译器和CPU,不管什么指令都不能和这条Memory Barrier指令重排序,也就是说通过插入内存屏障禁止在内存屏障前后的指令执行重排序优化。内存屏障另外一个作用是强制刷出各种CPU的缓存数据,因此任何CPU上的线程都能读取到这些数据的最新版本。
线程安全性获得保证
工作内存与主内存同步延迟现象导致的可见性问题
- 可以使用synchronized或volatile关键字解决,它们都可以使一个线程修改后的变量立即对其他线程可见。
对于指令重排导致的可见性问题和有序性问题
- 可以利用volatile关键字解决,因为volatile的另外一个作用就是禁止重排序优化。
volatile应用场景
单例模式双重检查
补充:缓存一致性
为什么这里主线程中某个值被更改后,其它线程能马上知晓呢?其实这里是用到了总线嗅探技术。
在说嗅探技术之前,首先谈谈缓存一致性的问题,就是当多个处理器运算任务都涉及到同一块主内存区域的时候,将可能导致各自的缓存数据不一。
为了解决缓存一致性的问题,需要各个处理器访问缓存时都遵循一些协议,在读写时要根据协议进行操作,这类协议主要有MSI、MESI等等。
MESI
当CPU写数据时,如果发现操作的变量是共享变量,即在其它CPU中也存在该变量的副本,会发出信号通知其它CPU将该内存变量的缓存行设置为无效,因此当其它CPU读取这个变量的时,发现自己缓存该变量的缓存行是无效的,那么它就会从内存中重新读取。
总线嗅探
那么是如何发现数据是否失效呢?
这里是用到了总线嗅探技术,就是每个处理器通过嗅探在总线上传播的数据来检查自己缓存值是否过期了,当处理器发现自己的缓存行对应的内存地址被修改,就会将当前处理器的缓存行设置为无效状态,当处理器对这个数据进行修改操作的时候,会重新从内存中把数据读取到处理器缓存中。
总线风暴
总线嗅探技术有哪些缺点?
由于Volatile的MESI缓存一致性协议,需要不断的从主内存嗅探和CAS循环,无效的交互会导致总线带宽达到峰值。因此不要大量使用volatile关键字,至于什么时候使用volatile、什么时候用锁以及Syschonized都是需要根据实际场景的。
参考
https://mp.weixin.qq.com/s/Oa3tcfAFO9IgsbE22C5TEg
既已览卷至此,何不品评一二: