volatile用处说明
在JDK1.2之前,java的内存模型实现总是从主存(即共享内存)读取变量,是不需要进行特别的注意的。而随着JVM的成熟和优化,现在在多线程环境下volatile关键字的使用变得非常重要。
下面给出一段代码,通过其运行结果来说明使用关键字volatile产生的差异,但实际上遇到了意料之外的问题:
- 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修饰的变量都要从内存中取值。《内存栅栏》
但看了这个帖子http://segmentfault.com/q/1010000000147713(也有人遇到同样的问题了)说,尝试了HotSpot的server和client两种模式,以及JDK1.3的classic,都没有效果,只有JDK1.2才能得到预期的结果。
哎!看来自己知识还是比较匮乏,看了下网友给出的答案,对于非volatile修饰的变量,尽管jvm的优化,会导致变量的可见性问题,但这种可见性的问题也只是在短时间内高并发的情况下发生,CPU执行时会很快刷新Cache,一般的情况下很难出现,而且出现这种问题是不可预测的,与jvm,
机器配置环境等都有关。