掉了两根头发，可算是把volatile整明白了

本来想着快过年了偷个懒休息下，没想到被兄弟们连续催更，没办法，博主暖男嘛，掐着人中也要更，兄弟们卷起来

volatile关键字可以说是Java虚拟机提供的最轻量级的同步机制，但对于为什么它只能保证可见性，不保证原子性，它又是如何禁用指令重排的，还有很多同学没彻底理解

相信我，坚持看完这篇文章，你将牢牢掌握一个Java核心知识点

先说它的两个作用：

• 保证变量在内存中对线程的可见性
• 禁用指令重排

每个字都认识，凑在一起就麻了

这两个作用通常很不容易被我们Java开发人员正确、完整地理解，以至于许多同学不能正确地使用volatile

关于可见性

不多bb，码来

publicclassVolatileTest{privatestaticvolatileint count =0;privatestaticvoidincrease(){
        count++;}publicstaticvoidmain(String[] args)throwsInterruptedException{for(int i =0; i <10; i++){newThread(()->{for(int j =0; j <10000; j++){increase();}}).start();}// 所有线程累加完成后输出while(Thread.activeCount()>2)Thread.yield();System.out.println(count);}}

代码很好理解，开了十个线程对同一个共享变量count做累加，每个线程累加1w次

count我们已经用volatile修饰，已经保证了count对十个线程在内存中的可见性，按理说十个线程执行完毕count的值应该10w

然鹅，运行多次，结果都远小于期望值

是哪个环节出了问题？

你肯定听过一句话：volatile只保证可见性，不保证原子性

这句话就是答案，但是依旧很多人没搞懂其中的奥秘

说来话长我长话短说，简单来讲就是 count++这个操作不是原子的，它是分三步进行

1. 从内存读取 count 的值
2. 执行 count + 1
3. 将 count 的新值写回

要彻底搞懂这个问题，我们得从字节码入手

下面是increase方法编译后的字节码

看不懂没关系，我们一行一行来看：

1. GETSTATIC：读取 count 的当前值
2. ICONST_1：将常量 1 加载到栈顶
3. IADD：执行+1
4. PUTSTATIC：写入count最新值

ICONST_1和IADD其实就是真正的++操作

关键点来了，volatile只能保证线程在GETSTATIC这一步拿到的值是最新的，但当该线程执行到下面几行指令时，这期间可能就有其它线程把count的值修改了，最终导致旧值把真正的新值覆盖

懂我意思吗

所以，并发编程中，只靠volatile修饰共享变量是不可靠的，最终还是要通过对关键方法加锁来保证线程安全

就如上面的demo，稍加修改就能实现真正的线程安全

最简单的，给increase方法加个synchronized （synchronized怎么实现线程安全的我就不啰嗦了，我以前讲过 synchronized底层实现原理）

privatesynchronizedstaticvoidincrease(){++count;}

run几下

这不就妥了嘛

到现在，对于以下两点你应该有了新的认知

• volatile保证变量在内存中对线程的可见性
• volatile只保证可见性，不保证原子性

关于指令重排

并发编程中，cpu自身和虚拟机为了提高执行效率，都会采用指令重排（在保证不影响结果的前提下，将某些代码乱序执行）

• 关于cpu：为了从分利用cpu，实际执行指令时会做优化；
• 关于虚拟机：在HotSpot vm中，为了提升执行效率，JIT(即时编译)模式也会做指令优化

指令重排在大部分场景下确实能提升执行效率，但有些场景对代码执行顺序是强依赖的，此时我们需要禁用指令重排，如下面这个场景

伪代码取自《深入理解Java虚拟机》：

其描述的场景是开发中常见配置读取过程，只是我们在处理配置文件时一般不会出现并发，所以没有察觉这会有问题。
试想一下，如果定义initialized变量时没有使用volatile修饰，就可能会由于指令重排序的优化，导致位于线程A中最后一条代码“initialized=true”被提前执行（这里虽然使用Java作为伪代码，但所指的重排序优化是机器级的优化操作，提前执行是指这条语句对应的汇编代码被提前执行），这样在线程B中使用配置信息的代码就可能出现错误，而volatile通过禁止指令重排则可以避免此类情况发生

禁用指令重排只需要将变量声明为volatile，是不是很神奇

我们来看看volatile是如何实现禁用指令重排的

也借用《深入理解Java虚拟机》的一个例子吧，比较好理解

这是个单例模式的实现，下面是它的部分字节码，红框中 mov%eax，0x150(%esi) 是对instance赋值

可以看到，在赋值后，还执行了 lock addl$0x0，(%esp) 指令，关键点就在这儿，这行指令相当于此处设置了个 内存屏障 ，有了内存屏障后，cpu或虚拟机在指令重排时就不能把内存屏障后面的指令提前到内存屏障前面，好好捋一下这段话

最后，留一个能加深大家对volatile理解的问题，兄弟们好好思考下：

Java代码明明是从上往下依次执行，为什么会出现指令重排这个问题？

ok我话说完