在
Java
中设置变量值的操作,除了
long
和
double
类型的变量外都是原子操作,也就是说,对于变量值的简单读写操作没有必要进行同步。这在
JVM 1.2
之前,
Java
的内存模型实现总是从主存读取变量,是不需要进行特别的注意的。而随着
JVM
的成熟和优化,现在在多线程环境下
volatile
关键字的使用变得非常重要。在当前的
Java
内存模型下,线程可以把变量保存在本地内存(比如机器的寄存器)中,而不是直接在主存中进行读写。这就可能造成一个线程在主存中修改了一个变量的值,而另外一个线程还继续使用它在寄存器中的变量值的拷贝,造成数据的不一致。要解决这个问题,只需要像在本程序中的这样,
把该变量声明为
volatile
(不稳定的)即可,这就指示
JVM
,这个变量是不稳定的,每次使用它都到主存中进行读取。
一般说来,多任务环境下各任务间共享的标志都应该加
volatile
修饰。
<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
Java
语言规范中指出:为了获得最佳速度,允许线程保存共享成员变量的私有拷贝,而且只有当线程进入或者离开同步代码块时,才能与共享变量的原始值对比。
volatile
是一个变量修饰符,而
synchronized
是一个方法或块的修饰符。所以我们使用这两种关键字来指定三种简单的存取变量的方式。
int i1; int geti1{return i1;}
volatile int i2; int geti2{return i2;}
int i3; synchronized int geti3{return i3};
geti1()
在当前线程中立即获取在
i1
变量中的值。
线程可以获得变量的本地拷贝,而所获得的变量的值并不一定与其他线程所获得的值相同。
特别是,如果其他的线程修改了
i1
的值,那么当前线程获得的
i1
的值可能与修改后的值有所差别。实际上,
Java
有一种主内存的机制,使用一个主内存来保存变量当前的正确的值。线程将变量的值拷贝到自己独立的内存中,而这些线程的内存拷贝可能与主内存中的值不同。所以实际当中可能发生这样的情况,在主内存中
i1
的值为
1
,线程
1
和线程
2
都更改了
i1
,但是却没把更新的值传回给主内存或其他线程中,那么可能在线程
1
中
i1
的值为
2
,线程
2
中
i1
的值却为
3
。
另一方面,
geti2()
可以有效的从主内存中获取
i2
的值。
一个
volatile
类型的变量不允许线程从主内存中将变量的值拷贝到自己的存储空间。
因此,一个声明为
volatile
类型的变量将在所有的线程中同步的获得数据,不论你在任何线程中更改了变量,其他的线程将立即得到同样的结果。由于线程存取或更改自己的数据拷贝有更高的效率,所以
volatile
类型变量在性能上有所消耗。
那么如果
volatile
变量已经可以使数据在线程间同步,那么
synchronizes
用来干什么呢?两者有两方面的不同。首先,
synchronized
获取和释放由监听器控制的锁,如果两个线程都使用一个监听器
(
即相同对象锁
)
,那么监听器可以强制在一个时刻只有一个线程能处理代码块,这是最一般的同步。另外,
synchronized
还能使内存同步。在实际当中,
synchronized
使得所有的线程内存与主内存相同步。所以
geti3()
的执行过程如下:
1.
线程从监听器获取对象的锁。
(
这里假设监听器非锁,否则线程只有等到监听器解锁才能获取对象锁
)
2.
线程内存更新所有的变量,
也就是说他将读取主内存中的变量使自己的变量保证有效
。
(JVM
会使用一个“脏”标志来最优化过程,使得仅仅具有“脏”标志变量被更新。详细的情况查询
JAVA
规范的
17.9)
3.
代码块被执行
(
在这个例子中,设置返回值为刚刚从主内存重置的
i3
当前的值。
)
4.
任何变量的变更将被写回到主内存中
。但是这个例子中
geti3()
没有什么变化。
5.
线程释放对象的锁给监听器。
所以
volatile
只能在线程内存和主内存之间同步一个变量的值,而
synchronized
则同步在线程内存和主内存之间的所有变量的值,并且通过锁住和释放监听器来实现。显然,
synchronized
在性能上将比
volatile
更加有所消耗
。
那么,原子操作在什么情况下不是线程安全的?主要的一点是他们也许确实是线程安全的,但是这没有被保证!
java
线程允许线程在自己的内存区保存变量的副本。允许线程使用本地的私有拷贝进行工作而非每次都使用主存的值是为了提高性能。
考虑下面的类:
class RealTimeClock
{
private int clkID;
public int clockID()
{
return clkID;
}
public void setClockID(int id)
{
clkID = id;
}
//...
}
class RealTimeClock
{
private int clkID;
public int clockID()
{
return clkID;
}
public void setClockID(int id)
{
clkID = id;
}
//...
}
现在考虑
RealTimeClock
的一个实例以及两个线程同时调用
setClockID
和
clockID
,并发生以下的事件序列:
T1 调用 setClockID(5)
T1 将 5 放入自己的私有工作内存
T2 调用 setClockID(10)
T2 将 10 放入自己的私有工作内存
T1 调用 clockID, 它返回 5
5 是从 T1 的私有工作内存返回的
对 clockI 的调用应该返回 10 ,因为这是被 T2 设置的,然而返回的是 5 , 因为读写操作是对私有工作内存的而非主存 。 赋值操作当然是原子的,但是因为 JVM 允许这种行为,因此线程安全不是一定的 ,同时, JVM 的这种行为也不是被保证的。
两个线程拥有自己的私有拷贝而不和主存一致。如果这种行为出现,那么私有本机变量和主存一致必须在以下两个条件下:
1 、变量使用 volatile 声明
2 、被访问的变量处于同步方法或者同步块中
如果变量被声明为 volatile ,在每次访问时都会和主存一致。这个一致性是由 java 语言保证的,并且是原子的,即使是 64 位的值。 ( 注意很多 JVM 没有正确的实现 volatile 关键字。你可以在 [url]www.javasoft.com[/url] 找到更多的信息。 ) 另外, 如果变量在同步方法或者同步块中被访问,当在方法或者块的入口处获得锁以及方法或者块退出时释放锁 时 变量被同步。
使用任何一种方法都可以保证 ClockID 返回 10 ,也就是正确的值。 变量访问的频度不同则你的选择的性能不同 。 如果你更新很多变量,那么使用 volatile 可能比使用同步更慢。 记住, 如果变量被声明为 volatile ,那么在每次访问时都会和主存一致。与此对照,使用同步时,变量只在获得锁和释放锁的时候和主存一致。但是同步使得代码有较少的并发性。
如果你更新很多变量 , 并且不想有每次访问都和主存进行同步的损失 , 或者你因为其它的原因想排除并发性时可以考虑使用同步。
T1 调用 setClockID(5)
T1 将 5 放入自己的私有工作内存
T2 调用 setClockID(10)
T2 将 10 放入自己的私有工作内存
T1 调用 clockID, 它返回 5
5 是从 T1 的私有工作内存返回的
对 clockI 的调用应该返回 10 ,因为这是被 T2 设置的,然而返回的是 5 , 因为读写操作是对私有工作内存的而非主存 。 赋值操作当然是原子的,但是因为 JVM 允许这种行为,因此线程安全不是一定的 ,同时, JVM 的这种行为也不是被保证的。
两个线程拥有自己的私有拷贝而不和主存一致。如果这种行为出现,那么私有本机变量和主存一致必须在以下两个条件下:
1 、变量使用 volatile 声明
2 、被访问的变量处于同步方法或者同步块中
如果变量被声明为 volatile ,在每次访问时都会和主存一致。这个一致性是由 java 语言保证的,并且是原子的,即使是 64 位的值。 ( 注意很多 JVM 没有正确的实现 volatile 关键字。你可以在 [url]www.javasoft.com[/url] 找到更多的信息。 ) 另外, 如果变量在同步方法或者同步块中被访问,当在方法或者块的入口处获得锁以及方法或者块退出时释放锁 时 变量被同步。
使用任何一种方法都可以保证 ClockID 返回 10 ,也就是正确的值。 变量访问的频度不同则你的选择的性能不同 。 如果你更新很多变量,那么使用 volatile 可能比使用同步更慢。 记住, 如果变量被声明为 volatile ,那么在每次访问时都会和主存一致。与此对照,使用同步时,变量只在获得锁和释放锁的时候和主存一致。但是同步使得代码有较少的并发性。
如果你更新很多变量 , 并且不想有每次访问都和主存进行同步的损失 , 或者你因为其它的原因想排除并发性时可以考虑使用同步。
转载于:https://blog.51cto.com/quinn/61509