目录：
留意复合类操作
解决num++操作的原子性问题
禁止指令重排序
总结
一、内存可见性
volatile是Java提供的一种轻量级的同步机制，在并发编程中，它也扮演着比较重要的角色。同synchronized相比（synchronized通常称为重量级锁），volatile更轻量级，相比使用synchronized所带来的庞大开销，倘若能恰当的合理的使用volatile，自然是美事一桩。
为了能比较清晰彻底的理解volatile，我们一步一步来分析。首先来看看如下代码
1 package volatileTest; 2 3 4 import hashMap.Main; 5 6 /** 7 * @author zsh 8 * @company wlgzs 9 * @create 2019-03-02 15:20 10 * @Describe volatile测试类·1 11 */ 12 public class Main1 { 13 14 boolean status = false; 15 16 /** 17 * 状态切换为true 18 */ 19 public void changeStatus(){ 20 status = true; 21 } 22 23 /** 24 * 若状态为true，则running。 25 */ 26 public void run(){ 27 if(status){ 28 System.out.println("running...."); 29 } 30 } 31 32 public static void main(String[] args) { 33 Main1 main1 = new Main1(); 34 for (int i = 0;i<50;i++){ 35 int finalI = i; 36 new Thread(){ 37 @Override 38 public void run() { 39 System.out.println("-------"+ finalI +"------"); 40 main1.changeStatus(); 41 main1.run(); 42 System.out.println("--------------------------"); 43 } 44 }.start(); 45 } 46 } 47 48 }
运行结果：
上面这个例子，在多线程环境里，假设线程A执行changeStatus()方法后,线程B运行run()方法，可以保证输出"running....."吗？
答案是NO!
这个结论会让人有些疑惑，可以理解。因为倘若在单线程模型里，先运行changeStatus方法，再执行run方法，自然是可以正确输出"running...."的；但是在多线程模型中，是没法做这种保证的。因为对于共享变量status来说，线程A的修改，对于线程B来讲，是"不可见"的。也就是说，线程B此时可能无法观测到status已被修改为true。那么什么是可见性呢？
所谓可见性，是指当一条线程修改了共享变量的值，新值对于其他线程来说是可以立即得知的。很显然，上述的例子中是没有办法做到内存可见性的。
Java内存模型
为什么出现这种情况呢，我们需要先了解一下JMM（java内存模型）
Java虚拟机有自己的内存模型（Java Memory Model，JMM），JMM可以屏蔽掉各种硬件和操作系统的内存访问差异，以实现让java程序在各种平台下都能达到一致的内存访问效果。
JMM决定一个线程对共享变量的写入何时对另一个线程可见，JMM定义了线程和主内存之间的抽象关系：共享变量存储在主内存(Main Memory)中，每个线程都有一个私有的本地内存（Local Memory），本地内存保存了被该线程使用到的主内存的副本拷贝，线程对变量的所有操作都必须在工作内存中进行，而不能直接读写主内存中的变量。这三者之间的交互关系如下
需要注意的是，JMM是个抽象的内存模型，所以所谓的本地内存，主内存都是抽象概念，并不一定就真实的对应cpu缓存和物理内存。当然如果是出于理解的目的，这样对应起来也无不可。
大概了解了JMM的简单定义后，问题就很容易理解了，对于普通的共享变量来讲，比如我们上文中的status，线程A将其修改为true这个动作发生在线程A的本地内存中，此时还未同步到主内存中去；而线程B缓存了status的初始值false，此时可能没有观测到status的值被修改了，所以就导致了上述的问题。那么这种共享变量在多线程模型中的不可见性如何解决呢？比较粗暴的方式自然就是加锁，但是此处使用synchronized或者Lock这些方式太重量级了，有点炮打蚊子的意思。比较合理的方式其实就是volatile
volatile具备两种特性，第一就是保证共享变量对所有线程的可见性。将一个共享变量声明为volatile后，会有以下效应：
1.当写一个volatile变量时，JMM会把该线程对应的本地内存中的变量强制刷新到主内存中去；
2.这个写会操作会导致其他线程中的缓存无效。
上面的例子只需将status声明为volatile，即可保证在线程A将其修改为true时，线程B可以立刻得知
volatile boolean status = false;
二、留意复合类操作
但是需要注意的是，我们一直在拿volatile和synchronized做对比，仅仅是因为这两个关键字在某些内存语义上有共通之处，volatile并不能完全替代synchronized，它依然是个轻量级锁，在很多场景下，volatile并不能胜任。看下这个例子：
1 package volatileTest; 2 3 import java.util.concurrent.CountDownLatch; 4 5 /** 6 * @author zsh 7 * @company wlgzs 8 * @create 2019-03-02 15:35 9 * @Describe volatile测试类·2 10 */ 11 public class Main2 { 12 public static volatile int num = 0; 13 //使用CountDownLatch来等待计算线程执行完 14 static CountDownLatch countDownLatch = new CountDownLatch(30); 15 16 public static void main(String[] args) throws InterruptedException { 17 //开启30个线程进行累加操作 18 for (int i = 0; i < 30; i++) { 19 new Thread() { 20 public void run() { 21 for (int j = 0; j < 10000; j++) { 22 num++;//自加操作 23 } 24 countDownLatch.countDown(); 25 } 26 }.start(); 27 } 28 //等待计算线程执行完 29 countDownLatch.await(); 30 System.out.println(num); 31 } 32 }
运行结果：
针对这个示例，一些同学可能会觉得疑惑，如果用volatile修饰的共享变量可以保证可见性，那么结果不应该是300000么?
问题就出在num++这个操作上，因为num++不是个原子性的操作，而是个复合操作。我们可以简单讲这个操作理解为由这三步组成:
1.读取 2.加一 3.赋值
所以，在多线程环境下，有可能线程A将num读取到本地内存中，此时其他线程可能已经将num增大了很多，线程A依然对过期的num进行自加，重新写到主存中，最终导致了num的结果不合预期，而是小于30000。
三、解决num++操作的原子性问题
针对num++这类复合类的操作，可以使用java并发包中的原子操作类原子操作类是通过循环CAS的方式来保证其原子性的。
1 package volatileTest; 2 3 import java.util.concurrent.CountDownLatch; 4 import java.util.concurrent.atomic.AtomicInteger; 5 6 /** 7 * @author zsh 8 * @company wlgzs 9 * @create 2019-03-02 15:52 10 * @Describe volatile测试类·3 11 */ 12 public class Main3 { 13 //使用原子操作类 14 public static AtomicInteger num = new AtomicInteger(0); 15 //使用CountDownLatch来等待计算线程执行完 16 static CountDownLatch countDownLatch = new CountDownLatch(30); 17 public static void main(String []args) throws InterruptedException { 18 //开启30个线程进行累加操作 19 for(int i=0;i<30;i++){ 20 new Thread(){ 21 public void run(){ 22 for(int j=0;j<10000;j++){ 23 num.incrementAndGet();//原子性的num++,通过循环CAS方式 24 } 25 countDownLatch.countDown(); 26 } 27 }.start(); 28 } 29 //等待计算线程执行完 30 countDownLatch.await(); 31 System.out.println(num); 32 } 33 }
运行结果：
关于原子类操作的基本原理，会在后面的章节进行介绍，此处不再赘述。
四、禁止指令重排序
volatile还有一个特性：禁止指令重排序优化。
重排序是指编译器和处理器为了优化程序性能而对指令序列进行排序的一种手段。但是重排序也需要遵守一定规则：
1.重排序操作不会对存在数据依赖关系的操作进行重排序。
比如：a=1;b=a; 这个指令序列，由于第二个操作依赖于第一个操作，所以在编译时和处理器运行时这两个操作不会被重排序。
2.重排序是为了优化性能，但是不管怎么重排序，单线程下程序的执行结果不能被改变
比如：a=1;b=2;c=a+b这三个操作，第一步（a=1)和第二步(b=2)由于不存在数据依赖关系，所以可能会发生重排序，但是c=a+b这个操作是不会被重排序的，因为需要保证最终的结果一定是c=a+b=3。
重排序在单线程模式下是一定会保证最终结果的正确性，但是在多线程环境下，问题就出来了，来开个例子，我们对第一个例子稍稍改进，再增加个共享变量a
1 package volatileTest; 2 3 /** 4 * @author zsh 5 * @company wlgzs 6 * @create 2019-03-02 15:57 7 * @Describe volatile测试类·4 8 */ 9 public class Main4 { 10 11 int a = 1; 12 boolean status = false; 13 14 /** 15 * 状态切换为true 16 */ 17 public void changeStatus(){ 18 a = 2;//1 19 status = true;//2 20 } 21 22 /** 23 * 若状态为true，则running。 24 */ 25 public void run(){ 26 if(status){//3 27 int b = a+1;//4 28 System.out.println(b); 29 } 30 } 31 32 public static void main(String[] args) { 33 Main4 main4 = new Main4(); 34 for (int i = 0;i<30000;i++){ 35 new Thread(){ 36 @Override 37 public void run() { 38 /*System.out.println("-------"+ fi +"------");*/ 39 main4.changeStatus(); 40 main4.run(); 41 System.out.println("--------------------------"); 42 } 43 }.start(); 44 } 45 } 46 }
假设线程A执行changeStatus后，线程B执行run，我们能保证在4处，b一定等于3么？
答案依然是无法保证！也有可能b仍然为2。上面我们提到过，为了提供程序并行度，编译器和处理器可能会对指令进行重排序，而上例中的1和2由于不存在数据依赖关系，则有可能会被重排序，先执行status=true再执行a=2。而此时线程B会顺利到达4处，而线程A中a=2这个操作还未被执行，所以b=a+1的结果也有可能依然等于2。
使用volatile关键字修饰共享变量便可以禁止这种重排序。若用volatile修饰共享变量，在编译时，会在指令序列中插入内存屏障来禁止特定类型的处理器重排序
volatile禁止指令重排序也有一些规则，简单列举一下：
1.当第二个操作是voaltile写时，无论第一个操作是什么，都不能进行重排序
2.当地一个操作是volatile读时，不管第二个操作是什么，都不能进行重排序
3.当第一个操作是volatile写时，第二个操作是volatile读时，不能进行重排序
五、总结：
简单总结下，volatile是一种轻量级的同步机制，它主要有两个特性：一是保证共享变量对所有线程的可见性；二是禁止指令重排序优化。同时需要注意的是，volatile对于单个的共享变量的读/写具有原子性，但是像num++这种复合操作，volatile无法保证其原子性，当然文中也提出了解决方案，就是使用并发包中的原子操作类，通过循环CAS地方式来保证num++操作的原子性。