本文共 5047 字,大约阅读时间需要 16 分钟。
在JDK1.2之前,Java的内存模型实现总是从主存(即共享内存)读取变量,是不需要进行特别的注意的。而随着JVM的成熟和优化,现在在多线程环境下volatile关键字的使用变得非常重要。
下面给出一段代码,通过其运行结果来说明使用关键字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 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 | public class Volatile extends Object implements Runnable { //value变量没有被标记为volatile private int value; //missedIt变量被标记为volatile private volatile boolean missedIt; //creationTime不需要声明为volatile,因为代码执行中它没有发生变化 private long creationTime; public Volatile() { value = 10 ; missedIt = false ; //获取当前时间,亦即调用Volatile构造函数时的时间 creationTime = System.currentTimeMillis(); } public void run() { print( "entering run()" ); //循环检查value的值是否不同 while ( value < 20 ) { //如果missedIt的值被修改为true,则通过break退出循环 if ( missedIt ) { //进入同步代码块前,将value的值赋给currValue int currValue = value; //在一个任意对象上执行同步语句,目的是为了让该线程在进入和离开同步代码块时, //将该线程中的所有变量的私有拷贝与共享内存中的原始值进行比较, //从而发现没有用volatile标记的变量所发生的变化 Object lock = new Object(); synchronized ( lock ) { //不做任何事 } //离开同步代码块后,将此时value的值赋给valueAfterSync int valueAfterSync = value; print( "in run() - see value=" + currValue + ", but rumor has it that it changed!" ); print( "in run() - valueAfterSync=" + valueAfterSync); break ; } } print( "leaving run()" ); } public void workMethod() throws InterruptedException { print( "entering workMethod()" ); print( "in workMethod() - about to sleep for 2 seconds" ); Thread.sleep( 2000 ); //仅在此改变value的值 value = 50 ; print( "in workMethod() - just set value=" + value); print( "in workMethod() - about to sleep for 5 seconds" ); Thread.sleep( 5000 ); //仅在此改变missedIt的值 missedIt = true ; print( "in workMethod() - just set missedIt=" + missedIt); print( "in workMethod() - about to sleep for 3 seconds" ); Thread.sleep( 3000 ); print( "leaving workMethod()" ); } /* *该方法的功能是在要打印的msg信息前打印出程序执行到此所化去的时间,以及打印msg的代码所在的线程 */ private void print(String msg) { //使用java.text包的功能,可以简化这个方法,但是这里没有利用这一点 long interval = System.currentTimeMillis() - creationTime; String tmpStr = " " + ( interval / 1000.0 ) + "000" ; int pos = tmpStr.indexOf( "." ); String secStr = tmpStr.substring(pos - 2 , pos + 4 ); String nameStr = " " + Thread.currentThread().getName(); nameStr = nameStr.substring(nameStr.length() - 8 , nameStr.length()); System.out.println(secStr + " " + nameStr + ": " + msg); } public static void main(String[] args) { try { //通过该构造函数可以获取实时时钟的当前时间 Volatile vol = new Volatile(); //稍停100ms,以让实时时钟稍稍超前获取时间,使print()中创建的消息打印的时间值大于0 Thread.sleep( 100 ); Thread t = new Thread(vol); t.start(); //休眠100ms,让刚刚启动的线程有时间运行 Thread.sleep( 100 ); //workMethod方法在main线程中运行 vol.workMethod(); } catch ( InterruptedException x ) { System.err.println( "one of the sleeps was interrupted" ); } } } |
按照以上的理论来分析,由于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修饰的变量都要从内存中取值。《内存栅栏》
但看了这个帖子(也有人遇到同样的问题了)说,尝试了HotSpot的server和client两种模式,以及JDK1.3的classic,都没有效果,只有JDK1.2才能得到预期的结果。
哎!看来自己知识还是比较匮乏,看了下网友给出的答案,对于非volatile修饰的变量,尽管jvm的优化,会导致变量的可见性问题,但这种可见性的问题也只是在短时间内高并发的情况下发生,CPU执行时会很快刷新Cache,一般的情况下很难出现,而且出现这种问题是不可预测的,与jvm, 机器配置环境等都有关。
姑且先这么理解吧!一点点积累。。。
正确的分析在这里:
这里附上分析结果时参考的帖子及文章
from: http://www.importnew.com/20566.html
原文出处: