volatile并不是用来解决多线程竞争问题的，而是用来修饰一些因为程序不可控因素导致变化的变量，比如访问底层硬件设备的变量，以提醒编译器不要对该变量的访问擅自进行优化。
int fun(int& a)
{
int b = a;
int c = a;
return a+b+c;
}
int main()
{
int a=1;
//.........做一些和a无关的事
return fun(a);
}
作者：KE meng
链接：http://www.zhihu.com/question/31459750/answer/52061391
来源：知乎
著作权归作者所有，转载请联系作者获得授权。
而且根本没有人用到了a,b,c三个变量,也没有任何人在修改a,b,c三个的值,所以编译器可能就直接
把这个函数优化成:
int main() { return 3; }
a的值虽然在当前上下文中不会被修改,但可能正在被其他线程修改啊.于是上面的优化
就不对了. 那么,volatile关键字在这里就可以帮助我们了,volatile关键字提醒编译器:
a可能随时被意外修改.
意外的意思是虽然当前这段代码里看起来a不会变,但可能别的地方正在修改a的值哦.
所谓"别的地方",某些情况下指的就是其他线程了.
int fun(volatile int& a)
{
int b = a;
int c = a;
return a+b+c;
}
int main()
{
volatile int a=1;
//.........做一些和a无关的事
return fun(a);
}
编译器就不敢优化了:
int fun(volatile int& a)
{
int b = a; //这里从内存读一下a吧,谁知道a还等不等于1呢
int c = a; //这里再从内存读一下a吧,谁知道a还等不等于1呢
return a+b+c; //这里也从内存读一下a吧,谁知道a还等不等于1呢
}
int main()
{
volatile int a=1;
//.........做一些和a无关的事
return fun(a); //完全不敢优化啊,鬼知道a变成多少了....
}
作者：KE meng
链接：http://www.zhihu.com/question/31459750/answer/52061391
来源：知乎
著作权归作者所有，转载请联系作者获得授权。
同理的,这段代码:
//.......... int a=0; //做一些和a无关的事 if(a==0) doSomething(); //.......... 编译器会发现,a肯定等于0啊,那我还if个毛啊,直接优化掉! //.......... int a=0; //做一些和a无关的事 doSomething(); //if被去掉了 //.......... 但,一旦添加了volatile,编译器就不敢优化了.例如: //.......... volatile int a=0; //做一些和a无关的事 if(a==0) doSomething(); //可不敢优化这里! 谁知道a变成多少了! //..........
这便是volatile的作用了.
static int* instance;
int& get_instance()
{
if( !instance ) { //检查如果单例的指针是0
此处有某种锁; //则在此处上锁
if( !instance ) { //再判断一次,以防等待锁期间有别的线程已经new完了
instance = new int; //确认无误则new之
}
}
return *instance;
}
int main()
{
int& i = get_instance();
i = 111;
return 1;
}
作者：KE meng
链接：http://www.zhihu.com/question/31459750/answer/52061391
来源：知乎
著作权归作者所有，转载请联系作者获得授权。
看看反汇编
作者：KE meng 链接：http://www.zhihu.com/question/31459750/answer/52061391 来源：知乎 著作权归作者所有，转载请联系作者获得授权。 ................... 010B1034 mov eax,dword ptr ds:[010B5100h] //读取instance指针到eax 010B1039 test eax,eax //检查eax是否为0 010B103B je get_instance+12h (010B1042h) //如果为0,则跳转下文010B1042处 ................... 010B103D //此处为下文中跳回的位置 ................... 010B1041 ret //get_instance()函数返回 ................... //010B1042从这里开始 010B1044 call dword ptr ds:[10B309Ch] //这里面call进去是malloc函数 010B104A add esp,4 //调整栈 010B104D mov dword ptr ds:[010B5100h],eax//将malloc出的写回instance地址 010B1052 jmp get_instance+0Dh (010B103Dh) //跳回前面的代码 .........................
哪里去了? 被编译器优化掉了.... 因为这里的优化逻辑很简单:
如果第一个判断某值==0成功,根本没必要去做第二个判断,因为编译器能发现此值没被这段代码
修改,同时编译器认为此值也不会被其他人"意外"修改,于是,苦心积虑所做的双检锁失效了.跟没写一样.
我们就改一行代码:
static int* volatile instance;
作者：KE meng 链接：http://www.zhihu.com/question/31459750/answer/52061391 来源：知乎 著作权归作者所有，转载请联系作者获得授权。 01201034 mov eax,dword ptr ds:[01205100h] //读取instance指针到eax 01201039 test eax,eax //检查eax是否为0 0120103B je get_instance+17h (01201047h)//如果为0,则跳转下文01201047h处 ................. 01201046 ret //get_instance()函数返回 ................. //以下为上文中跳转位置01201047: 01201047 mov eax,dword ptr ds:[01205100h] //再次读取instance指针到eax 0120104C test eax,eax //再次检查eax是否为0 0120104E jne get_instance+0Dh (0120103Dh) //如果非0,跳回上文return处 01201050 push 4 //如果还是0,往下执行malloc什么的. 01201052 call dword ptr ds:[120309Ch] //这里进去是malloc ........... 0120105B mov dword ptr ds:[01205100h],eax //将malloc好的值写回instance 01201060 jmp get_instance+0Dh (0120103Dh) //返回上文 ...........
终于,双检锁的逻辑正确了.因为volatile已经提示编译器,instance指针可能被"意外"修改.不要瞎做优化.
必须补充说明,volatile和锁没有一毛钱的关系,该加锁依然需要加锁.给变量添加volatile并不会让其自动拥有一个锁.所以该加锁还得加.
synchronized
同步块大家都比较熟悉，通过 synchronized 关键字来实现，所有加上synchronized 和 块语句，在多线程访问的时候，同一时刻只能有一个线程能够用
volatile
用volatile修饰的变量，线程在每次使用变量的时候，都会读取变量修改后的最的值。volatile很容易被误用，用来进行原子性操作。
下面看一个例子，我们实现一个计数器，每次线程启动的时候，会调用计数器inc方法，对计数器进行加一
public class Counter {
public static int count = 0;
public static void inc() {
//这里延迟1毫秒，使得结果明显
try {
Thread.sleep(1);
} catch (InterruptedException e) {
}
count++;
}
public static void main(String[] args) {
//同时启动1000个线程，去进行i++计算，看看实际结果
for (int i = 0; i < 1000; i++) {
new Thread(new Runnable() {
@Override
public void run() {
Counter.inc();
}
}).start();
}
//这里每次运行的值都有可能不同,可能为1000
System.out.println("运行结果:Counter.count=" + Counter.count);
}
}
1
1
运行结果:Counter.count=995
1
实际运算结果每次可能都不一样，本机的结果为：运行结果:Counter.count=995，可以看出，在多线程的环境下，Counter.count并没有期望结果是1000
1
1
很多人以为，这个是多线程并发问题，只需要在变量count之前加上volatile就可以避免这个问题，那我们在修改代码看看，看看结果是不是符合我们的期望
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
public class Counter {
public volatile static int count = 0;
public static void inc() {
//这里延迟1毫秒，使得结果明显
try {
Thread.sleep(1);
} catch (InterruptedException e) {
}
count++;
}
public static void main(String[] args) {
//同时启动1000个线程，去进行i++计算，看看实际结果
for (int i = 0; i < 1000; i++) {
new Thread(new Runnable() {
@Override
public void run() {
Counter.inc();
}
}).start();
}
//这里每次运行的值都有可能不同,可能为1000
System.out.println("运行结果:Counter.count=" + Counter.count);
}
}
运行结果:Counter.count=992
运行结果还是没有我们期望的1000，下面我们分析一下原因
在 java 中，jvm运行时刻内存的分配。其中有一个内存区域是jvm虚拟机栈，每一个线程运行时都有一个线程栈，
线程栈保存了线程运行时候变量值信息。当线程访问某一个对象时候值的时候，首先通过对象的引用找到对应在堆内存的变量的值，然后把堆内存
变量的具体值load到线程本地内存中，建立一个变量副本，之后线程就不再和对象在堆内存变量值有任何关系，而是直接修改副本变量的值，
在修改完之后的某一个时刻（线程退出之前），自动把线程变量副本的值回写到对象在堆中变量。这样在堆中的对象的值就产生变化了。
read and load 从主存复制变量到当前工作内存
use and assign 执行代码，改变共享变量值
store and write 用工作内存数据刷新主存相关内容
其中use and assign 可以多次出现
但是这一些操作并不是原子性，也就是 在read load之后，如果主内存count变量发生修改之后，线程工作内存中的值由于已经加载，不会产生对应的变化，所以计算出来的结果会和预期不一样
对于volatile修饰的变量，jvm虚拟机只是保证从主内存加载到线程工作内存的值是最新的
例如假如线程1，线程2 在进行read,load 操作中，发现主内存中count的值都是5，那么都会加载这个最新的值
在线程1堆count进行修改之后，会write到主内存中，主内存中的count变量就会变为6
线程2由于已经进行read,load操作，在进行运算之后，也会更新主内存count的变量值为6
导致两个线程及时用volatile关键字修改之后，还是会存在并发的情况。