volatile的作用是： 作为指令关键字，确保本条指令不会因编译器的优化而省略，
且要求每次直接读值.
简单地说就是防止编译器对代码进行优化.比如如下程序：
XBYTE[2] = 0x55;
XBYTE[2] = 0x56;
XBYTE[2] = 0x57;
XBYTE[2] = 0x58;
对外部硬件而言，上述四条语句分别表示不同的操作，会产生四种不同的动作，
但是编译器却会对上述四条语句进行优化，认为只有XBYTE[2] = 0x58
（即忽略前三条语句，只产生一条机器代码）。如果键入volatile，则编译器会
逐一的进行编译并产生相应的机器代码（产生四条代码）.
一个定义为volatile的变量是说这变量可能会被意想不到地改变，这样，编译器就不会去假设这个变量的值了。精确地说就是，优化器在用到这个变量时必须每次都小心地重新读取这个变量的值，而不是使用保存在寄存器里的备份。
下面是 volatile变量的几个例子：
1）.并行设备的硬件寄存器（如：状态寄存器）
2）.一个中断服务子程序中会访问到的非自动变量（Non - automatic variables)
3）.多线程应用中被几个任务共享的变量
这是区分C程序员和嵌入式系统程序员的最基本的问题：嵌入式系统程序员经常同 硬件、中断、RTOS等等打交道，所有这些都要求使用volatile变量。不懂得volatile 内容将会带来灾难。
C/C++多线程编程中不要使用volatile。
（注：这里的意思指的是指望volatile解决多线程竞争问题是有很大风险的，除非所用的环境系统不可靠才会为了保险加上volatile，或者是从极限效率考虑来实现很底层的接口。这要求编写者对程序逻辑走向很清楚才行，不然就会出错）
C++11标准中明确指出解决多线程的数据竞争问题应该使用原子操作或者互斥锁。
C和C++中的volatile并不是用来解决多线程竞争问题的，而是用来修饰一些因为程序
不可控因素导致变化的变量，比如访问底层硬件设备的变量，以提醒编译器不要对该 变量的访问擅自进行优化。
简单的来说，对访问共享数据的代码块加锁，已经足够保证数据访问的同步性，再加 volatile完全是多此一举。如果光对共享变量使用volatile修饰而在可能存在竞争的
操作中不加锁或使用原子操作对解决多线程竞争没有任何卵用，
volatile并不能保证操作的原子性，在读取、写入变量的过程中仍然可能被其他线程打断导致意外结果发生。
MSDN说得够清楚了:
The volatile keyword in C++11 ISO Standard code is to be
used only do not use it for inter - thread ommunication.
volatile int m_nC
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：138620次
积分：2159
积分：2159
排名：第14104名
原创：44篇
转载：188篇
评论：24条
(41)(16)(20)(70)(11)(9)(8)(5)(2)(1)(4)(5)(1)(1)(1)(1)(1)(1)(10)(7)(2)(1)(2)(1)(21)(1)2008年9月 .NET技术大版内专家分月排行榜第一
2010年 总版技术专家分年内排行榜第一2009年 总版技术专家分年内排行榜第一
2011年 总版技术专家分年内排行榜第二
本帖子已过去太久远了，不再提供回复功能。让天下没有难学的技术
聊聊并发（一）深入分析Volatile的实现原理
聊聊并发（一）深入分析Volatile的实现原理
本文属于作者原创，原文发表于InfoQ：
在多线程并发编程中synchronized和Volatile都扮演着重要的角色，Volatile是轻量级的synchronized，它在多处理器开发中保证了共享变量的“可见性”。可见性的意思是当一个线程修改一个共享变量时，另外一个线程能读到这个修改的值。它在某些情况下比synchronized的开销更小，本文将深入分析在硬件层面上Inter处理器是如何实现Volatile的，通过深入分析能帮助我们正确的使用Volatile变量。
在多个线程之间能够被共享的变量被称为共享变量。共享变量包括所有的实例变量，静态变量和数组元素。他们都被存放在堆内存中，Volatile只作用于共享变量。
Memory Barriers
是一组处理器指令，用于实现对内存操作的顺序限制。
Cache line
缓存中可以分配的最小存储单位。处理器填写缓存线时会加载整个缓存线，需要使用多个主内存读周期。
Atomic operations
不可中断的一个或一系列操作。
缓存行填充
cache line fill
当处理器识别到从内存中读取操作数是可缓存的，处理器读取整个缓存行到适当的缓存（L1，L2，L3的或所有）
如果进行高速缓存行填充操作的内存位置仍然是下次处理器访问的地址时，处理器从缓存中读取操作数，而不是从内存。
当处理器将操作数写回到一个内存缓存的区域时，它首先会检查这个缓存的内存地址是否在缓存行中，如果存在一个有效的缓存行，则处理器将这个操作数写回到缓存，而不是写回到内存，这个操作被称为写命中。
write misses the cache
一个有效的缓存行被写入到不存在的内存区域。
Volatile的官方定义
Java语言规范第三版中对volatile的定义如下： java编程语言允许线程访问共享变量，为了确保共享变量能被准确和一致的更新，线程应该确保通过排他锁单独获得这个变量。Java语言提供了volatile，在某些情况下比锁更加方便。如果一个字段被声明成volatile，java线程内存模型确保所有线程看到这个变量的值是一致的。
为什么要使用Volatile
Volatile变量修饰符如果使用恰当的话，它比synchronized的使用和执行成本会更低，因为它不会引起线程上下文的切换和调度。
Volatile的实现原理
那么Volatile是如何来保证可见性的呢？在x86处理器下通过工具获取JIT编译器生成的汇编指令来看看对Volatile进行写操作CPU会做什么事情。
Java代码：
instance = new Singleton();//instance是volatile变量
汇编代码：
0x01a3de1d: movb $0x0,0x1104800(%esi);0x01a3de24: lock addl $0x0,(%esp);
有volatile变量修饰的共享变量进行写操作的时候会多第二行汇编代码，通过查IA-32架构软件开发者手册可知，lock前缀的指令在多核处理器下会引发了两件事情。
将当前处理器缓存行的数据会写回到系统内存。
这个写回内存的操作会引起在其他CPU里缓存了该内存地址的数据无效。
处理器为了提高处理速度，不直接和内存进行通讯，而是先将系统内存的数据读到内部缓存（L1,L2或其他）后再进行操作，但操作完之后不知道何时会写到内存，如果对声明了Volatile变量进行写操作，JVM就会向处理器发送一条Lock前缀的指令，将这个变量所在缓存行的数据写回到系统内存。但是就算写回到内存，如果其他处理器缓存的值还是旧的，再执行计算操作就会有问题，所以在多处理器下，为了保证各个处理器的缓存是一致的，就会实现缓存一致性协议，每个处理器通过嗅探在总线上传播的数据来检查自己缓存的值是不是过期了，当处理器发现自己缓存行对应的内存地址被修改，就会将当前处理器的缓存行设置成无效状态，当处理器要对这个数据进行修改操作的时候，会强制重新从系统内存里把数据读到处理器缓存里。
这两件事情在IA-32软件开发者架构手册的第三册的多处理器管理章节（第八章）中有详细阐述。
Lock前缀指令会引起处理器缓存回写到内存。Lock前缀指令导致在执行指令期间，声言处理器的 LOCK# 信号。在多处理器环境中，LOCK# 信号确保在声言该信号期间，处理器可以独占使用任何共享内存。（因为它会锁住总线，导致其他CPU不能访问总线，不能访问总线就意味着不能访问系统内存），但是在最近的处理器里，LOCK＃信号一般不锁总线，而是锁缓存，毕竟锁总线开销比较大。在8.1.4章节有详细说明锁定操作对处理器缓存的影响，对于Intel486和Pentium处理器，在锁操作时，总是在总线上声言LOCK#信号。但在P6和最近的处理器中，如果访问的内存区域已经缓存在处理器内部，则不会声言LOCK#信号。相反地，它会锁定这块内存区域的缓存并回写到内存，并使用缓存一致性机制来确保修改的原子性，此操作被称为“缓存锁定”，缓存一致性机制会阻止同时修改被两个以上处理器缓存的内存区域数据。
一个处理器的缓存回写到内存会导致其他处理器的缓存无效。IA-32处理器和Intel 64处理器使用MESI（修改，独占，共享，无效）控制协议去维护内部缓存和其他处理器缓存的一致性。在多核处理器系统中进行操作的时候，IA-32 和Intel 64处理器能嗅探其他处理器访问系统内存和它们的内部缓存。它们使用嗅探技术保证它的内部缓存，系统内存和其他处理器的缓存的数据在总线上保持一致。例如在Pentium和P6 family处理器中，如果通过嗅探一个处理器来检测其他处理器打算写内存地址，而这个地址当前处理共享状态，那么正在嗅探的处理器将无效它的缓存行，在下次访问相同内存地址时，强制执行缓存行填充。
Volatile的使用优化
著名的Java并发编程大师Doug lea在JDK7的并发包里新增一个队列集合类LinkedTransferQueue，他在使用Volatile变量时，用一种追加字节的方式来优化队列出队和入队的性能。
追加字节能优化性能？这种方式看起来很神奇，但如果深入理解处理器架构就能理解其中的奥秘。让我们先来看看LinkedTransferQueue这个类，它使用一个内部类类型来定义队列的头队列（Head）和尾节点（tail），而这个内部类PaddedAtomicReference相对于父类AtomicReference只做了一件事情，就将共享变量追加到64字节。我们可以来计算下，一个对象的引用占4个字节，它追加了15个变量共占60个字节，再加上父类的Value变量，一共64个字节。
/** head of the queue */
private transient final PaddedAtomicReference&QNode&
/** tail of the queue */
private transient final PaddedAtomicReference&QNode&
static final class PaddedAtomicReference &T& extends AtomicReference &T& {
// enough padding for 64bytes with 4byte refs
Object p0, p1, p2, p3, p4, p5, p6, p7, p8, p9, pa, pb, pc, pd,
PaddedAtomicReference(T r) {
public class AtomicReference &V& implements java.io.Serializable {
private volatile V
//省略其他代码
为什么追加64字节能够提高并发编程的效率呢？ 因为对于英特尔酷睿i7，酷睿， Atom和NetBurst， Core Solo和Pentium M处理器的L1，L2或L3缓存的高速缓存行是64个字节宽，不支持部分填充缓存行，这意味着如果队列的头节点和尾节点都不足64字节的话，处理器会将它们都读到同一个高速缓存行中，在多处理器下每个处理器都会缓存同样的头尾节点，当一个处理器试图修改头接点时会将整个缓存行锁定，那么在缓存一致性机制的作用下，会导致其他处理器不能访问自己高速缓存中的尾节点，而队列的入队和出队操作是需要不停修改头接点和尾节点，所以在多处理器的情况下将会严重影响到队列的入队和出队效率。Doug lea使用追加到64字节的方式来填满高速缓冲区的缓存行，避免头接点和尾节点加载到同一个缓存行，使得头尾节点在修改时不会互相锁定。
那么是不是在使用Volatile变量时都应该追加到64字节呢？不是的。在两种场景下不应该使用这种方式。第一：缓存行非64字节宽的处理器，如P6系列和奔腾处理器，它们的L1和L2高速缓存行是32个字节宽。第二：共享变量不会被频繁的写。因为使用追加字节的方式需要处理器读取更多的字节到高速缓冲区，这本身就会带来一定的性能消耗，共享变量如果不被频繁写的话，锁的几率也非常小，就没必要通过追加字节的方式来避免相互锁定。
原创文章，转载请注明： 转载自本文链接地址:
花名清英，并发网()创始人，畅销书《Java并发编程的艺术》作者，蚂蚁金服技术专家。目前工作于支付宝微贷事业部，关注互联网金融，并发编程和敏捷实践。微信公众号aliqinying。
Latest posts by 方 腾飞 ()
Related posts:
(8 votes, average: 4.50 out of 5)
Loading...
TrackBack 地址Java多线程之synchronized和volatile的比较
在做多线程并发处理时，经常需要对资源进行可见性访问和互斥同步操作。有时候，我们可能从前辈那里得知我们需要对资源进行 volatile 或是 synchronized 关键字修饰处理。可是，我们却不知道这两者之间的区别，我们无法分辨在什么时候应该使用哪一个关键字。本文就针对这个问题，展开讨论。
内存语义分析
happens-before 模型简介
如果你单从字面上的意思来理解 happens-before 模型，你可能会觉得这是在说某一个操作在另一个操作之前执行。不过，学习完 happens-before 之后，你就不会还这样理解了。以下是《 并发的艺术》书上对 happens-before 的定义：
在 JMM(Java Memory Model) 中，如果一个操作执行的结果需要对另一个操作可见，那么这两个操作之间必须存在 happens-before 关系。这里提到的两个操作既可以在一个线程之内，也可以是在不同的线程之间。
volatile 的内存语义
对于多线程编程来说，每个线程是可以拥有共享内存中变量的一个拷贝，这一点在后面还是会讲到，这里就不作过多说明。如果一个变量被 volatile 关键字修饰时，那么对这的变量的写是将本地内存中的拷贝刷新到共享内存中；对这个变量的读会有一些不同，读的时候是无视他的本地内存的拷贝的，只是从共享变量中去读取数据。
synchronized 的内存语义
我们说 synchronized 实际上是对变量进行加锁处理。那么不管是读也好，写也好都是基于对这个变量的加锁操作。如果一个变量被 synchronized 关键字修饰，那么对这的变量的写是将本地内存中的拷贝刷新到共享内存中；对这个变量的读就是将共享内存中的值刷新到本地内存，再从本地内存中读取数据。因为全过程中变量是加锁的，其他线程无法对这个变量进行读写操作。所以可以理解成对这个变量的任何操作具有原子性，即线程是安全的。
上面的一些说明或是定义可能会有一些乏味枯燥，也不太好理解。这里我们就列举一些例子来说明，这样比较具体和形象一些。
volatile 可见性测试
RunThread.java
public class RunThread extends Thread {
private boolean isRunning =
public boolean isRunning() {
return isR
public void setRunFlag(boolean flag) {
isRunning =
public void run() {
System.out.println(&I'm come in...&);
boolean first =
while(isRunning) {
if (first) {
System.out.println(&I'm in while...&);
System.out.println(&I'll go out.&);
MyRun.java
public class MyRun {
public static void main(String[] args) throws InterruptedException {
RunThread thread = new RunThread();
thread.start();
Thread.sleep(100);
thread.setRunFlag(false);
System.out.println(&flag is reseted: & + thread.isRunning());
对于上面的例子只是一个很普通的多线程操作，这里我们很容易就得到了 RunThread 线程在 while 中进入了死循环。
我们可以在 main() 方法里看到一句 Thread.sleep(100) ，结合前面说到的 happens-before 内存模型，可知下面的 thread.setRunFlag(false) 并不会 happens-before 子线程中的 while 。这样一来，虽然主线程中对 isRunning 进行了修改，然而对子线程中的 while 来说，并没有改变，所以这就会引发在 while 中的死循环。
在这种情况下，线程工作时的内存模型像下面这样
在这里，可能你会奇怪，为什么会有两个&内存块&？这是出于多线程的性能考虑的。虽然对象以及成员变量分配的内存是在共享内存中的，不过对于每个线程而言，还是可以拥有这个对象的拷贝，这样做的目的是为了加快程序的执行，这也是现代多核处理器的一个显著特征。从上面的内存模型可以看出，Java的线程是直接与它自身的工作内存（本地内存）交互，工作内存再与共享内存交互。这样就形成了一个非原子的操作，在Java里多线程的环境下非原子的操作是很危险的。这个我们都已经知道了，因为这可能会被异步的读写操作所破坏。
这里工作内存被 while 占用，无法去更新主线程对共享内存 isRunning 变量的修改。所以，如果我们想要打破这种限制，可以通过 volatile 关键字来处理。通过 volatile 关键字修饰 while 的条件变量，即 isRunning。就像下面这样修改 RunThread.java 代码：vcD4NCjxwcmUgY2xhc3M9"brush:">
private volatile boolean isRunning =
这样一来， volatile 修改了 isRunning 的可见性，使得主线程的 thread.setRunFlag(false) 将会 happens-before 子线程中的 while 。最终，使得子线程从 while 的循环中跳出，问题解决。
下面我们来看看 volatile 是如何修改了 isRunning 的可见性的吧。
这里，因为 isRunning 被 volatile 修饰，那么当子线程想要访问工作内存中的 inRunning 时，被强制地直接从共享内存中获取。而共享内存中的 isRunning 被主线程修改过了，已经被修改成了 false ，while 被打破，这样子线程就从 while 的循环中跳出来了。
volatile 原子性测试
volatile 确实有很多优点，可是它却有一个致命的缺点，那就是 volatile 并不是原子操作。也就是在多线程的情况，仍然是不安全的。
可能，这个时候你会发问说，既然 volatile 保证了它在线程间的可见性，那么在什么时候修改它，怎么修改它，对于其他线程是可见的，某一个线程读到的都会是修改过的值，为什么还要说它还是不安全的呢？
我们通过一个例子来说明吧，这样更形象一些。大家看下面这样一段代码：
public class DemoNoProtected {
static class MyThread extends Thread {
static int count = 0;
private static void addCount() {
for (int i = 0; i & 100; i++) {
System.out.println(&count = & + count);
public void run() {
addCount();
public static void main(String[] args) {
MyThread[] threads = new MyThread[100];
for (int i = 0; i & 100; i++) {
threads[i] = new MyThread();
for (int i = 0; i & 100; i++) {
threads[i].start();
count = 300
count = 300
count = 300
count = 400
count = 7618
count = 7518
count = 9918
这是一个未经任何处理的，很直白的过程。可是它的结果，也很直白。其实这个结果并不让人意外，从我们学习Java的时候，就知道Java的多线程并不安全。是不是从上面的学习中，你感觉这个可以通过 volatile 关键字解决？既然你这么说，那么我们就来试一试，给 count 变量添加 volatile 关键字，如下：
public class DemoVolatile {
static class MyThread extends Thread {
static volatile int count = 0;
public static void main(String[] args) {
count = 100
count = 300
count = 400
count = 200
count = 9852
count = 9752
count = 9652
count = 8154
count = 8054
不知道这个结果是不是会让你感觉到意外。对于 count 的混乱的数字倒是好理解一些，应该多个线程同时修改时就发生这样的事情。可是我们在结果为根本找不到逻辑上的最大值&10000&，这就有一些奇怪了。因为从逻辑上来说， volatile修改了 count 的可见性，对于线程 A 来说，它是可见线程 B 对 count 的修改的。只是从结果中并没有体现这一点。
我们说，volatile并没有保证线程安全。在上面子线程中的 addCount() 方法里，执行的是 count++ 这样一句代码。而像 count++ 这样一句代码从学习Java变量自增的第一堂课上，老师就应该强调过它的执行过程。count++ 可以类比成以下的过程：
tmp = tmp + 1;
可见，count++ 并非原子操作。任何两个线程都有可能将上面的代码分离进行，安全性便无从谈起了。
所以，到这里我们知道了 volatile 可以改变变量在线程之间的可见性，却不能改变线程之间的同步。而同步操作则需要其他的操作来保证。
synchronized 同步测试
上面说到 volatile 不能解决线程的安全性问题，这是因为 volatile 不能构建原子操作。而在多线程编程中有一个很方便的同步处理，就是 synchronized 关键字。下面来看看 synchronized 是如何处理多线程同步的吧，代码如下：
public class DemoSynchronized {
static class MyThread extends Thread {
static int count = 0;
private synchronized static void addCount() {
for (int i = 0; i & 100; i++) {
System.out.println(&count = & + count);
public void run() {
addCount();
public static void main(String[] args) {
MyThread[] threads = new MyThread[100];
for (int i = 0; i & 100; i++) {
threads[i] = new MyThread();
for (int i = 0; i & 100; i++) {
threads[i].start();
count = 100
count = 200
count = 300
count = 9800
count = 9900
count = 10000
通过 synchronized 我们可以很容易就获得了理想的结果。而关于 synchronized 关键字的内存模型可以这样来表示：
某一个线程在访问一个被 synchronized 修饰的变量时，会对此变量的共享内存进行加锁，那么这个时候其他线程对其的访问就会被互斥。 synchronized 的内部实现其实也是锁的概念。
《Java多线程编程核心技术》 《Java并发编程的艺术》
(window.slotbydup=window.slotbydup || []).push({
id: '2467140',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467141',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467142',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467143',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467148',
container: s,
size: '1000,90',
display: 'inlay-fix'