【Java并发编程】之五：volatile变量修饰符—意料之外的问题（含代码）

转载请注明出处：http://blog.youkuaiyun.com/ns_code/article/details/17101369

    volatile用处说明

    在JDK1.2之前，Java的内存模型实现总是从主存（即共享内存）读取变量，是不需要进行特别的注意的。而随着JVM的成熟和优化，现在在多线程环境下volatile关键字的使用变得非常重要。

在当前的Java内存模型下，线程可以把变量保存在本地内存（比如机器的寄存器）中，而不是直接在主存中进行读写。这就可能造成一个线程在主存中修改了一个变量的值，而另外一个线程还继续使用它在寄存器中的变量值的拷贝，造成数据的不一致。

要解决这个问题，就需要把变量声明为volatile（也可以使用同步，参见http://blog.youkuaiyun.com/ns_code/article/details/17288243），这就指示JVM，这个变量是不稳定的，每次使用它都到主存中进行读取。一般说来，多任务环境下，各任务间共享的变量都应该加volatile修饰符。

Volatile修饰的成员变量在每次被线程访问时，都强迫从共享内存中重读该成员变量的值。而且，当成员变量发生变化时，强迫线程将变化值回写到共享内存。这样在任何时刻，两个不同的线程总是看到某个成员变量的同一个值。

Java语言规范中指出：为了获得最佳速度，允许线程保存共享成员变量的私有拷贝，而且只当线程进入或者离开同步代码块时才将私有拷贝与共享内存中的原始值进行比较。

这样当多个线程同时与某个对象交互时，就必须注意到要让线程及时的得到共享成员变量的变化。而volatile关键字就是提示JVM：对于这个成员变量，不能保存它的私有拷贝，而应直接与共享成员变量交互。

volatile是一种稍弱的同步机制，在访问volatile变量时不会执行加锁操作，也就不会执行线程阻塞，因此volatilei变量是一种比synchronized关键字更轻量级的同步机制。

使用建议：在两个或者更多的线程需要访问的成员变量上使用volatile。当要访问的变量已在synchronized代码块中，或者为常量时，没必要使用volatile。

由于使用volatile屏蔽掉了JVM中必要的代码优化，所以在效率上比较低，因此一定在必要时才使用此关键字。

示例程序

下面给出一段代码，通过其运行结果来说明使用关键字volatile产生的差异，但实际上遇到了意料之外的问题：

[java]  view plain  copy

 

1. public class Volatile extends Object implements Runnable {  
2.     //value变量没有被标记为volatile  
3.     private int value;    
4.     //missedIt变量被标记为volatile  
5.     private volatile boolean missedIt;  
6.     //creationTime不需要声明为volatile，因为代码执行中它没有发生变化  
7.     private long creationTime;   
8.   
9.     public Volatile() {  
10.         value = 10;  
11.         missedIt = false;  
12.         //获取当前时间，亦即调用Volatile构造函数时的时间  
13.         creationTime = System.currentTimeMillis();  
14.     }  
15.   
16.     public void run() {  
17.         print("entering run()");  
18.   
19.         //循环检查value的值是否不同  
20.         while ( value < 20 ) {  
21.             //如果missedIt的值被修改为true，则通过break退出循环  
22.             if  ( missedIt ) {  
23.                 //进入同步代码块前，将value的值赋给currValue  
24.                 int currValue = value;  
25.                 //在一个任意对象上执行同步语句，目的是为了让该线程在进入和离开同步代码块时，  
26.                 //将该线程中的所有变量的私有拷贝与共享内存中的原始值进行比较，  
27.                 //从而发现没有用volatile标记的变量所发生的变化  
28.                 Object lock = new Object();  
29.                 synchronized ( lock ) {  
30.                     //不做任何事  
31.                 }  
32.                 //离开同步代码块后，将此时value的值赋给valueAfterSync  
33.                 int valueAfterSync = value;  
34.                 print("in run() - see value=" + currValue +", but rumor has it that it changed!");  
35.                 print("in run() - valueAfterSync=" + valueAfterSync);  
36.                 break;   
37.             }  
38.         }  
39.         print("leaving run()");  
40.     }  
41.   
42.     public void workMethod() throws InterruptedException {  
43.         print("entering workMethod()");  
44.         print("in workMethod() - about to sleep for 2 seconds");  
45.         Thread.sleep(2000);  
46.         //仅在此改变value的值  
47.         value = 50;  
48.         print("in workMethod() - just set value=" + value);  
49.         print("in workMethod() - about to sleep for 5 seconds");  
50.         Thread.sleep(5000);  
51.         //仅在此改变missedIt的值  
52.         missedIt = true;  
53.         print("in workMethod() - just set missedIt=" + missedIt);  
54.         print("in workMethod() - about to sleep for 3 seconds");  
55.         Thread.sleep(3000);  
56.         print("leaving workMethod()");  
57.     }  
58.   
59. /* 
60. *该方法的功能是在要打印的msg信息前打印出程序执行到此所化去的时间，以及打印msg的代码所在的线程 
61. */  
62.     private void print(String msg) {  
63.         //使用java.text包的功能，可以简化这个方法，但是这里没有利用这一点  
64.         long interval = System.currentTimeMillis() - creationTime;  
65.         String tmpStr = "    " + ( interval / 1000.0 ) + "000";       
66.         int pos = tmpStr.indexOf(".");  
67.         String secStr = tmpStr.substring(pos - 2, pos + 4);  
68.         String nameStr = "        " + Thread.currentThread().getName();  
69.         nameStr = nameStr.substring(nameStr.length() - 8, nameStr.length());      
70.         System.out.println(secStr + " " + nameStr + ": " + msg);  
71.     }  
72.   
73.     public static void main(String[] args) {  
74.         try {  
75.             //通过该构造函数可以获取实时时钟的当前时间  
76.             Volatile vol = new Volatile();  
77.   
78.             //稍停100ms，以让实时时钟稍稍超前获取时间，使print（）中创建的消息打印的时间值大于0  
79.             Thread.sleep(100);    
80.   
81.             Thread t = new Thread(vol);  
82.             t.start();  
83.   
84.             //休眠100ms，让刚刚启动的线程有时间运行  
85.             Thread.sleep(100);    
86.             //workMethod方法在main线程中运行  
87.             vol.workMethod();  
88.         } catch ( InterruptedException x ) {  
89.             System.err.println("one of the sleeps was interrupted");  
90.         }  
91.     }  
92. }  

按照以上的理论来分析，由于value变量不是volatile的，因此它在main线程中的改变不会被Thread-0线程（在main线程中新开启的线程）马上看到，因此Thread-0线程中的while循环不会直接退出，它会继续判断missedIt的值，由于missedIt是volatile的，当main线程中改变了missedIt时，Thread-0线程会立即看到该变化，那么if语句中的代码便得到了执行的机会，由于此时Thread-0依然没有看到value值的变化，因此，currValue的值为10，继续向下执行，进入同步代码块，因为进入前后要将该线程内的变量值与共享内存中的原始值对比，进行校准，因此离开同步代码块后，Thread-0便会察觉到value的值变为了50，那么后面的valueAfterSync的值便为50，最后从break跳出循环，结束Thread-0线程。

意料之外的问题

但实际的执行结果如下：

从结果中可以看出，Thread-0线程并没有进入while循环，说明Thread-0线程在value的值发生变化后，missedIt的值发生变化前，便察觉到了value值的变化，从而退出了while循环。这与理论上的分析不符，我便尝试注释掉value值发生改变与missedIt值发生改变之间的线程休眠代码Thread.sleep(5000)，以确保Thread-0线程在missedIt的值发生改变前，没有时间察觉到value值的变化。但执行的结果与上面大同小异（可能有一两行顺序不同，但依然不会打印出if语句中的输出信息）。

问题分析

在JDK1.7~JDK1.3之间的版本上输出结果与上面基本大同小异，只有在JDK1.2上才得到了预期的结果，即Thread-0线程中的while循环是从if语句中退出的，这说明Thread-0线程没有及时察觉到value值的变化。

这里需要注意：volatile是针对JIT带来的优化，因此JDK1.2以前的版本基本不用考虑，另外，在JDK1.3.1开始，开始运用HotSpot虚拟机，用来代替JIT。因此，是不是HotSpot的问题呢？这里需要再补充一点：

JIT或HotSpot编译器在server模式和client模式编译不同，server模式为了使线程运行更快，如果其中一个线程更改了变量boolean flag 的值，那么另外一个线程会看不到，因为另外一个线程为了使得运行更快所以从寄存器或者本地cache中取值，而不是从内存中取值，那么使用volatile后，就告诉不论是什么线程，被volatile修饰的变量都要从内存中取值。《内存栅栏》

但看了这个帖子http://segmentfault.com/q/1010000000147713（也有人遇到同样的问题了）说，尝试了HotSpot的server和client两种模式，以及JDK1.3的classic，都没有效果，只有JDK1.2才能得到预期的结果。

哎！看来自己知识还是比较匮乏，看了下网友给出的答案，对于非volatile修饰的变量，尽管jvm的优化，会导致变量的可见性问题，但这种可见性的问题也只是在短时间内高并发的情况下发生，CPU执行时会很快刷新Cache，一般的情况下很难出现，而且出现这种问题是不可预测的，与jvm, 机器配置环境等都有关。

姑且先这么理解吧！一点点积累。。。

正确的分析在这里：http://blog.youkuaiyun.com/ns_code/article/details/17382679

这里附上分析结果时参考的帖子及文章

http://segmentfault.com/q/1010000000147713

http://www.iteye.com/problems/98213

http://www.oldcaptain.cc/articles/2013/08/21/1377092100971.html