上篇https://www.jianshu.com/p/24fb647c1750介绍了volatile可见性，下面介绍下volatile原理和为什么不能保证原子性。
一、简述Java内存模型
Java内存模型分为主内存和线程工作内存两大类。
主内存： 多个线程共享的内存。如下图所示，方法区和堆属于主内存区域。
线程工作内存： 每个线程独享的内存。如下图所示，虚拟机栈、本地方法栈、程序计数器属于线程独享的工作内存。
image.png
Java内存模型规定：所有变量都需要存储在主内存中，线程工作内存保存了变量在主内存中的副本，线程对变量的所有操作都在工作内存中进行，执行结束后在同步到主内存中去。这里必然会存在时间差，在这个时间差内，该线程对副本的操作，对于其他线程是不见的，从而造成了可见性问题。
image.png
二、指令重排序
JVM对代码进行编译优化，导致代码可能并不是按照代码编写顺序执行，而是按照JVM进行编译优化后的顺序执行。指令重排序对并发编程安全性有很大影响，所以提供了一些happens-before规则定义一些禁止编译优化的场景。
2.1 什么是happens-before
happens-before： A happens-before B就是A先行发生于B（这种说法不是很准确），定义为hb(A, B)。在Java内存模型中，happens-before的意思是前一个操作的结果可以被后续操作获取。
2.2 为什么需要happens-before
JVM会对代码进行编译优化，会出现指令重排序情况，为了避免编译优化对并发编程安全性的影响，需要happens-before规则定义一些禁止编译优化的场景，保证并发编程的正确性。以双重检查单例示例进行分析：
/**
* 懒汉式 双重检查锁实现单例
*/
public class LazyDoubleCheckSingleton {
private static LazyDoubleCheckSingleton instance = null;
private LazyDoubleCheckSingleton(){}
/**
* 双重检查锁 减小加锁粒度 相对于LazySynchronizedSingleton提升性能 减少不必要的锁开销
* @return
*/
public static LazyDoubleCheckSingleton getInstance(){
if (instance == null){
synchronized (LazyDoubleCheckSingleton.class){
if (instance == null){
//CPU执行时候会转换成JVM指令执行
//1.分配内存给对象 2.初始化对象 3.将初始化对象和内存地址建立关联，赋值
//4.用户初次访问
//存在问题指令重排序 有可能2 3顺序颠倒
instance = new LazyDoubleCheckSingleton();
}
}
}
return instance;
}
}
上述代码中instance = new LazyDoubleCheckSingleton()并不是原子操作 ，JVM会分解成以下几个命令执行：
1.给对象分配内存
2.初始化对象
3.将初始化对象和内存地址建立关联
按照上面的分解顺序（1->2->3）执行不存在任何问题，但是由于JVM编译优化的存在，可能导致2和3步骤颠倒，即按1->3->2顺序执行（这就是指令重排序）。按照1->3->2顺序执行，在多线程环境中执行getInstance就有可能出现instance已经和初始对象内存建立关联，但是对象还没有初始化完成的情况，即执行if (instance == null)的时候instance != null 直接返回没有初始化完成的instance，导致再使用instance实例的时候报错。volatile关键字是可以解决指令重排序问题的一种方式，具体解决方式如下：
//添加volatile解决指令重排序问题
private volatile static LazyDoubleCheckSingleton instance = null;
2.3、happens-before规则
1.程序次序规则： 在一个线程内一段代码的执行结果是有序的。就是还会指令重排，但是随便它怎么排，结果是按照我们代码的顺序生成的不会变。
2.管程锁定规则：就是无论是在单线程环境还是多线程环境，对于同一个锁来说，一个线程对这个锁解锁之后，另一个线程获取了这个锁都能看到前一个线程的操作结果！(管程是一种通用的同步原语，synchronized就是管程的实现）
3.volatile变量规则：就是如果一个线程先去写一个volatile变量，然后一个线程去读这个变量，那么这个写操作的结果一定对读的这个线程可见。
4.线程启动规则：在主线程A执行过程中，启动子线程B，那么线程A在启动子线程B之前对共享变量的修改结果对线程B可见。
5.线程终止规则：在主线程A执行过程中，子线程B终止，那么线程B在终止之前对共享变量的修改结果在线程A中可见。也称线程join()规则。
6.线程中断规则：对线程interrupt()方法的调用先行发生于被中断线程代码检测到中断事件的发生，可以通过Thread.interrupted()检测到是否发生中断。
7.传递性规则：这个简单的，就是happens-before原则具有传递性，即hb(A, B) ， hb(B, C)，那么hb(A, C)。
8.对象终结规则：这个也简单的，就是一个对象的初始化的完成，也就是构造函数执行的结束一定 happens-before它的finalize()方法。
三、volatile的作用
保证共享变量的可见性： 是通过store和load指令完成的；也就是对volatile变量执行写操作时，会在写操作后加入一条store指令，即强迫线程将最新的值刷新到主内存中；而在读操作时，会加入一条load指令，即强迫从主内存中读入变量的值。lock前缀指令实际上相当于一个内存屏障。
防止局部指令重排序： happens-before规则中的volatile变量规则规定了一个线程先去写一个volatile变量，然后一个线程去读这个变量，那么这个写操作的结果一定对读的这个线程可见。
四、volatile如何防止指令重排序
volatile是通过内存屏障来防止指令重排序的。
硬件层面的内存屏障分为Load Barrier 和 Store Barrier即读屏障和写屏障。
对于Load Barrier来说，在指令前插入Load Barrier，可以让高速缓存中的数据失效，强制从新从主内存加载数据。
对于Store Barrier来说，在指令后插入Store Barrier，能让写入缓存中的最新数据更新写入主内存，让其他线程可见。
Java内存屏障类型把上述两种内存屏障两两组合，如下图所示：
image.png
volatile防止指令重排序具体步骤：
1.在每个volatile写操作的前面插入一个StoreStore屏障。
2.在每个volatile写操作的后面插入一个StoreLoad屏障。
3.在每个volatile读操作的后面插入一个LoadLoad屏障。
4.在每个volatile读操作的后面插入一个LoadStore屏障。
image.png
image.png
volatile可见性总结：
volatile解决的是多线程共享变量可见性问题，但是被volatile修饰的变量操作并非具有原子性。
五、volatile为什么不能保证原子性
以下的例子创建10个线程，对一个静态变量count进行累计加法计算（每个线程遍历1000次），期望值是10000。
示例1：
仅仅将变量count修饰为volatile
public class VolatileTest {
private static final String TAG = VolatileTest.class.getName();
//volatile修饰的变量count
private static volatile int count = 0;
//测试volatile为什么不能保证原子性
public void testVolatile01() {
CountDownLatch countDownLatch = new CountDownLatch(1);
for (int i=0;i<10;i++) {
Thread thread = new Thread(() -> {
try {
countDownLatch.await();
for (int j=0;j < 1000;j++) {
count ++;
}
} catch (InterruptedException e) {
e.printStackTrace();
}
});
thread.start();
}
try {
Thread.sleep(500);
countDownLatch.countDown();
Thread.sleep(5000);
} catch (InterruptedException e) {
e.printStackTrace();
}
Log.i(TAG, "testVolatile01==>count="+count);
}
}
运行结果：
testVolatile01==>count=9213
显然运行结果不是10000。
示例2：
不仅将count变量修饰为volatile，还将count++操作外层用synchronized代码块加锁
public class VolatileTest {
private static final String TAG = VolatileTest.class.getName();
private static volatile int count = 0;
private Object object = new Object();
//测试volatile为什么不能保证原子性，如果要保证原子性，必须加锁synchronized
public void testVolatile02() {
CountDownLatch countDownLatch = new CountDownLatch(1);
for (int i=0;i<10;i++) {
Thread thread = new Thread(() -> {
try {
countDownLatch.await();
for (int j=0;j < 1000;j++) {
//加同步锁
synchronized (object) {
count ++;
}
}
} catch (InterruptedException e) {
e.printStackTrace();
}
});
thread.start();
}
try {
Thread.sleep(500);
countDownLatch.countDown();
Thread.sleep(5000);
} catch (InterruptedException e) {
e.printStackTrace();
}
//testVolatile02==>count=10000
Log.i(TAG, "testVolatile02==>count="+count);
}
}
运行结果：
testVolatile02==>count=10000
可以看到volatile关键字不能保证原子性，除非加synchronized锁才可以保证原子性。
根据上篇学到的JMM模型：
bdeafb031b30e85dad64b42d69b9c04.png
如果变量count被volatile修饰后，但没有用synchronized代码块包裹count++操作，此时如果线程B完成了count=count+1操作，并将结果加lock后同步到主内存区域中，根据上述的可见性原理，此时线程A感知到主内存中的count值发生变化，线程A的工作内存中计算操作或许没有完成，即将执行的count=count+1是可能被视为无效，工作内存被清理，所以计算出来的count的值最终可能不是10000，即说明了volatile不能保证原子性，解决办法就是加synchronized锁。
网友评论