一.概念
volatile是JVM提供的轻量级的同步机制，它有如下三大特性：
- 保证可见性
- 不保证原子性
- 禁止指令重排（保证有序性）
二.JMM之可见性
JMM（Java内存模型Java Memory Model 简称JMM）本身就是一种抽象的概念并不真实存在，它描述的是一组规范或规则，通过这组规范定义了程序中的各个变量（包括实例字段、静态变量、构成数组对象的元素）的访问方式。
JMM关于同步的规定：
- 线程解锁前，必须把共享变量的值刷从工作内存回主内存
- 线程加锁前，必须读取主内存中的最新值到自己的工作内存
- 加锁解锁都是同一把锁
由于JVM运行程序的实体是线程，而每个线程创建时JVM都会为其创建一个工作内存（栈空间），工作内存是每个线程私有的数据区域，而Java内存模型中规定所有变量都存储在主内存，主内存是共享内存区域的，所有线程都可以访问，但线程对变量的操作（读取赋值等）必须在工作内存中进行，首先要将变量从主内存拷贝到自己的工作内存空间，然后对变量进行操作，操作完成后再将变量写回主内存中，不能直接操作主内存中的变量，各个线程中的工作内存中存储者主内存中的变量副本，因此不同的线程之间无法访问对方的工作内存，线程间的通信（传值）必须通过主内存来完成，其简要访问过程如下图：
三.可见性
通过前面对JMM的介绍，我们知道各个线程对主内存中共享变量的操作都是各个线程各自拷贝到自己的工作内存中进行操作然后再写回主内存中的。
那么这就可能存在一个线程AAA修改了共享变量X的值但还未写回主内存时，另一个线程BBB又对主内存中的同一个共享变量X进行操作，但此时AAA线程的工作内存中的共享变量X对线程BBB来说并不可见，因此这种工作内存与主内存同步延迟现象就造成了可见性问题。
四.可见性的代码验证
import java.util.concurrent.TimeUnit;
/** * 假设这是主物理内存 */
class MyData {
//volatile int number = 0;
int number = 0;
public void addTo60() {
this.number = 60;
}
}
/** * 开始验证volatile的可见性 * 1.假设 int number = 0，且number变量之前没有volatile关键字修饰 ==> 很明显main线程没有感知到number的改变 * 2.假设 使用了volatile修饰 ==> 在AAA线程休眠3秒后修改了number变量，main线程立马感知到了 */
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();
//main线程就一直在这里循环等待，直到number的值不为0
while (myData.number == 0){
}
//按道理这个值是不可能被打印出来的，因为主线程运行的时候，number的值一直为0，所以跳不出循环
//如果能输出这句话，就说明AAA线程在睡眠3秒后，更新了number的值，重新写出主内存中，并且被main线程感知到了
System.out.println(Thread.currentThread().getName() + "\t mission is over");
}
}
由于没有volatile修饰MyData类的成员变量number，main线程会卡在while (myData.number == 0){}中。要想正确结束，就要使用volatile进行修饰该成员变量。
五.volatile不保证原子性
原子性是什么意思呢？
不可分割，完整性，即某个线程在做某个具体业务时，中间不可被加塞或者被分割。需要整体完整，要么同时成功，要么同时失败。
volatile不保证原子性案例演示：
class MyData2 {
/** * volatile 修饰的关键字，是为了增加主线程和线程之间的可见性，只要有一个线程修改了内存中的值其它线程就能立马感知 */
volatile int number = 0;
public void addPlusPlus() {
number++;
}
}
public class VolatileAtomicityDemo {
public static void main(String[] args) {
MyData2 myData = new MyData2();
//创建20个线程，每个线程执行addPlusPlus方法1000次
for (int i = 0; i < 20; i++) {
new Thread(()->{
//里面
for (int j = 0; j < 1000; j++) {
myData.addPlusPlus();
}
},String.valueOf(i)).start();
}
//需要等待上面的20个线程全部计算完毕后，再使用main线程获取最终的结果值
//这里判断线程数是否大于2？因为默认是有两个线程的，一个是main线程，一个是gc线程
while (Thread.activeCount() > 2){
//yield表示不执行，让出cup资源重新抢夺
Thread.yield();
}
//查看最终的值
//假设volatile保证原子性，那么输出的值应该为： 20 * 1000 = 20000
System.out.println(Thread.currentThread().getName() + "\t finally number value:" + myData.number);
}
}
结果很明显，number的值不确定，但是总是小于20000！
六.volatile不保证原子性理论解释
number++在多线程下是非线程安全的。
我们可以查看字节码，可看出number++被编译成3条指令。
假设我们没有加synchronized，那么第一步就可能存在着，三个线程同时通过getfield命令，拿到主存中的n值，然后这三个线程在自己的工作内存中进行加1的操作，但他们并发进行iadd指令的时候，因为只能一个进行写入操作，所以其它操作会被挂起，假设1线程先进行了写操作，在写完后，volatile具有可见性，应该需要告诉其它两个线程主存中的n值已经改变了，但是因为太快了，其它两个线程陆续执行iadd命令，进行写入操作，这就造成了其它线程没有接收到主内存中n的改变，从而覆盖了原来的值，出现写丢失，这样也就让最终的结果始终少于20000.
七.volatile不保证原子性问题解决
首先肯定是可以加synchronized解决，但它是重量级的同步机制，性能上有所顾虑。
那么如何不加synchronized解决number++在多线程下线程不安全的问题？答案：使用AtomicInteger。
import java.util.concurrent.atomic.AtomicInteger;
class MyData2 {
/** * volatile 修饰的关键字，是为了增加主线程和线程之间的可见性，只要有一个线程修改了内存中的值其它线程就能立马感知 */
volatile int number = 0;
//原子操作类
AtomicInteger number2 = new AtomicInteger();
public void addPlusPlus() {
number++;
}
public void addPlusPlus2() {
number2.getAndIncrement(); //先获取然后自增1
}
}
public class VolatileAtomicityDemo {
public static void main(String[] args) {
MyData2 myData = new MyData2();
//创建20个线程，每个线程执行addPlusPlus方法1000次
for (int i = 0; i < 20; i++) {
new Thread(()->{
//里面
for (int j = 0; j < 1000; j++) {
myData.addPlusPlus();
myData.addPlusPlus2();
}
},String.valueOf(i)).start();
}
//需要等待上面的20个线程全部计算完毕后，再使用main线程获取最终的结果值
//这里判断线程数是否大于2？因为默认是有两个线程的，一个是main线程，一个是gc线程
while (Thread.activeCount() > 2){
//yield表示不执行，让出cup资源重新抢夺
Thread.yield();
}
//查看最终的值
//假设volatile保证原子性，那么输出的值应该为： 20 * 1000 = 20000
System.out.println(Thread.currentThread().getName() + "\t finally number value:" + myData.number);
System.out.println(Thread.currentThread().getName() + "\t finally number2 value:" + myData.number2);
}
}
输出结果为：
main finally number value:17982
main finally number2 value:20000
八.指令重排
案例1：
计算机在执行程序时，为了提高性能，编译器和处理器的常常会对指令做重排，一般分以下3种：
单线程环境里面确保程序最终执行结果和代码顺序执行的结果一致。
处理器在进行重排序时必须要考虑指令之间的数据依赖性 。
多线程环境中线程交替执行，由于编译器优化重排的存在，两个线程中使用的变量能否保证一致性是无法确定的，结果无法预测。
比如：
public void mySort{
int x = 11;//语句1
int y = 12;//语句2
× = × + 5;//语句3
y = x * x;//语句4
}
可重排序列：
- 1234
- 1243
- 1324
- 2134
问题：语句3、4可以重排后到第一个吗？不能！因为有依赖关系！
案例2：
观察以下程序
public class ReSortSeqDemo{
int a = 0;
boolean flag = false;
public void method01(){
a = 1;//语句1
flag = true;//语句2
}
public void method02(){
if(flag){
a = a + 5; //语句3
}
System.out.println("retValue: " + a);//可能是6或1或5或0
}
}
多线程环境中线程交替执行method01()和method02()，由于编译器优化重排的存在，两个线程中使用的变量能否保证一致性是无法确定的，结果无法预测。
volatile实现禁止指令重排优化，从而避免多线程环境下程序出现乱序执行的现象 。
九.单例模式在多线程环境下可能存在安全问题
懒汉式单例模式
public class SingletonDemo {
private static SingletonDemo instance = null;
private SingletonDemo () {
System.out.println(Thread.currentThread().getName() + "\t 我是构造方法SingletonDemo");
}
public static SingletonDemo getInstance() {
if(instance == null) {
instance = new SingletonDemo();
}
return instance;
}
public static void main(String[] args) {
// 这里的 == 是比较内存地址
System.out.println(SingletonDemo.getInstance() == SingletonDemo.getInstance());
System.out.println(SingletonDemo.getInstance() == SingletonDemo.getInstance());
System.out.println(SingletonDemo.getInstance() == SingletonDemo.getInstance());
System.out.println(SingletonDemo.getInstance() == SingletonDemo.getInstance());
}
}
输出结果：
main 我是构造方法singletonDemo
true
true
true
true
但是，在多线程环境运行上述代码，能保证单例吗？
public class SingletonDemo {
private static SingletonDemo instance = null;
private SingletonDemo () {
System.out.println(Thread.currentThread().getName() + "\t 我是构造方法SingletonDemo");
}
public static SingletonDemo getInstance() {
if(instance == null) {
instance = new SingletonDemo();
}
return instance;
}
public static void main(String[] args) {
for (int i = 0; i < 10; i++) {
new Thread(()->{
SingletonDemo.getInstance();
},String.valueOf(i)).start();
}
}
}
输出结果:
0 我是构造方法SingletonDemo
1 我是构造方法SingletonDemo
9 我是构造方法SingletonDemo
4 我是构造方法SingletonDemo
8 我是构造方法SingletonDemo
5 我是构造方法SingletonDemo
6 我是构造方法SingletonDemo
7 我是构造方法SingletonDemo
3 我是构造方法SingletonDemo
2 我是构造方法SingletonDemo
很显然，不能保证单例。
解决方法1:用synchronized修饰方法getInstance()，但它属重量级同步机制，使用时慎重。
public synchronized static SingletonDemo getInstance() {
if(instance == null) {
instance = new SingletonDemo();
}
return instance;
}
输出结果：
0 我是构造方法SingletonDemo
解决方法2:DCL（Double Check Lock双端检锁机制）
public class SingletonDemo{
private SingletonDemo(){
}
private volatile static SingletonDemo instance = null;
public static SingletonDemo getInstance() {
if(instance == null) {
synchronized(SingletonDemo.class){
if(instance == null){
instance = new SingletonDemo();
}
}
}
return instance;
}
}
输出结果：
0 我是构造方法SingletonDemo
DCL中volatile解析 :
如果private volatile static SingletonDemo instance = null;这段代码不加volatile从结果上看也许也是正确的，但是如果没有加volatile，就可能发生优化重排。
原因在于某一个线程执行到第一次检测，读取到的instance不为null时，instance的引用对象可能没有完成初始化。
instance = new SingletonDemo();可以分为以下3步完成(伪代码)：
memory = allocate(); //1.分配对象内存空间
instance(memory); //2.初始化对象
instance = memory; //3.设置instance指向刚分配的内存地址，此时instance != null
步骤2和步骤3不存在数据依赖关系，而且无论重排前还是重排后程序的执行结果在单线程中并没有改变，因此这种重排优化是允许的。
memory = allocate(); //1.分配对象内存空间
instance = memory;//3.设置instance指向刚分配的内存地址，此时instance! =null，但是对象还没有初始化完成!
instance(memory);//2.初始化对象
但是指令重排只会保证串行语义的执行的一致性(单线程)，但并不会关心多线程间的语义一致性。
;可以分为以下3步完成(伪代码)：
memory = allocate(); //1.分配对象内存空间
instance(memory); //2.初始化对象
instance = memory; //3.设置instance指向刚分配的内存地址，此时instance != null
步骤2和步骤3不存在数据依赖关系，而且无论重排前还是重排后程序的执行结果在单线程中并没有改变，因此这种重排优化是允许的。
memory = allocate(); //1.分配对象内存空间
instance = memory;//3.设置instance指向刚分配的内存地址，此时instance! =null，但是对象还没有初始化完成!
instance(memory);//2.初始化对象
但是指令重排只会保证串行语义的执行的一致性(单线程)，但并不会关心多线程间的语义一致性。
所以当一条线程访问instance不为null时，由于instance实例未必已初始化完成，也就造成了线程安全问题。
文章评论