volatile用处说明
在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修饰的变量都要从内存中取值。《内存栅栏》
但看了这个帖子http://segmentfault.com/q/1010000000147713(也有人遇到同样的问题了)说,尝试了HotSpot的server和client两种模式,以及JDK1.3的classic,都没有效果,只有JDK1.2才能得到预期的结果。
哎!看来自己知识还是比较匮乏,看了下网友给出的答案,对于非volatile修饰的变量,尽管jvm的优化,会导致变量的可见性问题,但这种可见性的问题也只是在短时间内高并发的情况下发生,CPU执行时会很快刷新Cache,一般的情况下很难出现,而且出现这种问题是不可预测的,与jvm, 机器配置环境等都有关。
姑且先这么理解吧!一点点积累。。。
正确的分析在这里:http://blog.csdn.net/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
from: http://www.importnew.com/20566.html
原文出处: 兰亭风雨