java volatile关键字的理解

转载：http://shmilyaw-hotmail-com.iteye.com/blog/1672779

一个多线程的示例引发的问题

在讨论这个关键字之前先看一个多线程的示例代码：

public class RaceCondition {
private static boolean done;
public static void main(final String[] args) throws InterruptedException{
new Thread(
new Runnable() {
public void run() {
int i = 0;
while(!done) { i++; }
System.out.println("Done!");
}
}
).start();
System.out.println("OS: " + System.getProperty("os.name"));
Thread.sleep(2000);
done = true;
System.out.println("flag done set to true");
}
}

这部分代码主要是设置了一个static变量done。main函数的主线程会打印一些必要的信息之后修改该变量的值。而另外一个派生的线程则一直在读取done的信息，根据信息来判断下一步的行为。总的来说就是一个线程等另一个线程修改的数值结果。

如果运行这一段代码，会是什么结果呢？

下面是在我的具体执行环境下的情况：

OS: Linux
flag done set to true

比较有意思的就是代码执行到这里的时候并没有完全退出来，只是一直停在这里。

从代码的字面含义来看，当main函数主线程将done设置为true的时候，派生的线程应该读取到这个值然后跳出循环的啊，为什么没有跳出来呢？

先别急，如果我们换一种方式来执行上面的代码试试，就会发现不一样的结果了：

如果我们输入如下的命令：

java -d32 RaceCondition

这次执行的结果会是：

OS: Linux
flag done set to true
Done!

这么看来，实在是太诡异了。到底是怎么回事呢？

第一步分析

实际上，首先这个问题就在于我们执行代码的时候所采用的执行方式。java的命令执行模式是和平台相关的。当我们在linux平台用java RaceCondition的时候，java默认采用的是server模式。而后面用java -d32 RaceCondition，就是手动的指示采用client模式来执行。这么说来问题就出在执行模式的差别。

确实，server模式和client模式执行java代码会有一些差别。server模式会jit的时候对代码做一些优化。更进一步来说，我们前面的问题就在于server模式的优化。为什么这么一优化之后结果就不对了呢？我们可以看下面jvm的结构图来做下一步分析。

上面图中，每个java线程都有一套自己独立的栈、指令寄存器、缓存等线程本地存储空间。这样，每次线程执行的时候，一些线程本地的变量或者传入的参数可以在线程内部存储空间处理。而这个问题的关键也在于线程的本地存储空间。在对前面的代码进行优化之后，线程读取到done变量会读取一个副本到本地的存储空间。这样以后每次线程访问这个变量的时候，不会跑到原来定义该变量的内存中来读取，而是直接读取自身的那个副本。这样，我们才会看到第一种方式的执行不会结束。而前面我们在client模式下看到的结果是因为没有这些优化，每次还是从done变量的内存中来读取。

那么，如果要解决上面那个问题，有哪些办法呢？

一种选项，volatile

如果说为了结果这样一个问题，我们可以有好几种选项，比如说将done声明为原子数据类型，或者采用synchronized方式来访问它。我们这里可以考虑一下volatile这种方式。

volatile表示它告诉jit编译器，不要对所修饰的变量进行任何优化。这样，每次每个线程访问修饰的变量时，每次都是访问内存中这个独一无二的变量，不会有其他的本地拷贝。

volatile提供唯一的内存访问地址容易让人产生一些误解。觉得volatile变量看起来可以实现多线程的安全访问。实际未必。

volatile不保证多个线程访问的原子性

比如说我们有多个线程要访问一个网站的计数器，假设该变量为count。那么每个对该变量进行一次递增的代码是count++;粗粗看来用volatile应该可以满足了。实际上会有问题。

我们对count递增的操作实际的执行细节里是细分成了三个步骤。1.读取count，2.递增count 3.将修改后的数值写会内存。问题就在于，当有多个线程访问的时候，会出现竞争条件，可能导致数据错误。

volatile也不能保证线程的互斥访问

和synchronized的关键字不一样，volatile对于访问变量没有严格限制。所以可以同时有多个线程进行读写操作。这样就不能保证线程安全的。

性能方面

既然volatile修饰的变量就是放在内存中，所以每次每个线程访问的时候都要来访问内存。这样和直接访问寄存器或者缓存比起来要慢不少。如果有大量的线程要访问某些变量，都要去访问内存的话。会带来性能方面的影响。在实际的计算机体系结构中，对于volatile变量的读取性能已经和非volatile变量的读取非常接近，几乎可以忽略了。只有对volatile的写操作会相对慢一些。

volatile一些应用的场景

看了前面的分析，让人觉得有点沮丧。似乎这东西没什么用。从前面对性能的分析，我们可以看到一个应用。那就是如果只有一个线程进行数据的写，大部分的线程只是都数据的话,volatile是一个不错的选项。包括前面的那个简单的示例，如果只是一个普通变量的访问，没有特殊要求，用volatile是一种很简便的解决方法。

和用synchronized等线程同步机制来限制代码，volatile可以用一种很简单的方式来满足一些多线程访问需求。

对于volatile更多详细的应用可以参考这篇文章.

　　　应用场景推荐：

　　　变量的值不依赖于以前的值：比如I++这种操作

　　　作为状态标志：比如boolean类型的变量

　　　在ReentrantLock中的使用volatile变量在表示状态

总结

Volatile变量是一种可以在某种情况下简化多线程编程的手法。它限制了多线程访问的jit优化，在某些对性能要求比较高的情况下需要慎重考虑。