C++中的mutable和volatile以及java中volatile关键字的作用、原理

参考：
C++中的mutable和volatile.
volatile关键字的作用、原理.

1、mutable

在C++中，mutable是为了突破const的限制而设置的。被mutable修饰的变量，将永远处于可变的状态，即使在一个const函数中，甚至结构体变量或者类对象为const，其mutable成员也可以被修改。

struct  ST    
{   
  int a;    
  mutable int b;   
};  
const ST st={1,2};    
st.a=11;    //编译错误    
st.b=22;    //允许  

mutable在类中只能够修饰非静态数据成员。mutable 数据成员的使用看上去像是骗术，因为它能够使const函数修改对象的数据成员。然而，明智地使用 mutable 关键字可以提高代码质量，因为它能够让你向用户隐藏实现细节，而无须使用不确定的东西。我们知道，如果类的成员函数不会改变对象的状态，那么这个成员函数一般会声明成const的。但是，有些时候，我们需要在const的函数里面修改一些跟类状态无关的数据成员，那么这个数据成员就应该被mutalbe来修饰。

class  ST    
{  
    int a;   
    mutable int showCount;    
    void Show()const;   
};  
ST::Show()   
{      
    a=1;//错误，不能在const成员函数中修改普通变量   
    showCount++;//正确  
}  

const承诺的是一旦某个变量被其修饰，那么只要不使用强制转换(const_cast)，在任何情况下该变量的值都不会被改变，无论有意还是无意，而被const修饰的函数也一样，一旦某个函数被const修饰，那么它便不能直接或间接改变任何函数体以外的变量的值，即使是调用一个可能造成这种改变的函数都不行。这种承诺在语法上也作出严格的保证，任何可能违反这种承诺的行为都会被编译器检查出来。
　　mutable的承诺是如果某个变量被其修饰，那么这个变量将永远处于可变的状态，即使在一个const函数中。这与const形成了一个对称的定义，一个永远不变，而另外一个是永远可变。
　　看一个变量或函数是否应该是const，只需看它是否应该是constant或invariant，而看一个变量是否应该是mutable,也只需看它是否是forever mutative。
　　这里出现了令人纠结的3个问题：
　　1、为什么要保护类的成员变量不被修改？
　　2、为什么用const保护了成员变量，还要再定义一个mutable关键字来突破const的封锁线？
　　3、到底有没有必要使用const 和 mutable这两个关键字？
　　保护类的成员变量不在成员函数中被修改，是为了保证模型的逻辑正确，通过用const关键字来避免在函数中错误的修改了类对象的状态。并且在所有使用该成员函数的地方都可以更准确的预测到使用该成员函数的带来的影响。而mutable则是为了能突破const的封锁线，让类的一些次要的或者是辅助性的成员变量随时可以被更改。没有使用const和mutable关键字当然没有错，const和mutable关键字只是给了建模工具更多的设计约束和设计灵活性，而且程序员也可以把更多的逻辑检查问题交给编译器和建模工具去做，从而减轻程序员的负担。

2、volatile

象const一样，volatile是一个类型修饰符。volatile修饰的数据,编译器不可对其进行执行期寄存于寄存器的优化。这种特性,是为了满足多线程同步、中断、硬件编程等特殊需要。遇到这个关键字声明的变量，编译器对访问该变量的代码就不再进行优化，从而可以提供对特殊地址的直接访问。
　　volatile原意是“易变的”，但这种解释简直有点误导人，应该解释为“直接存取原始内存地址”比较合适。“易变”是相对与普通变量而言其值存在编译器(优化功能)未知的改变情况(即不是通过执行代码赋值改变其值的情况)，而是因外在因素引起的，如多线程，中断等。编译器进行优化时，它有时会取一些值的时候，直接从寄存器里进行存取，而不是从内存中获取，这种优化在单线程的程序中没有问题，但到了多线程程序中，由于多个线程是并发运行的，就有可能一个线程把某个公共的变量已经改变了，这时其余线程中寄存器的值已经过时，但这个线程本身还不知道，以为没有改变，仍从寄存器里获取，就导致程序运行会出现未定义的行为。并不是因为用volatile修饰了的变量就是“易变”了，假如没有外因，即使用volatile定义，它也不会变化。而加了volatile修饰的变量，编译器将不对其相关代码执行优化，而是生成对应代码直接存取原始内存地址。
　　一般说来，volatile用在如下的几个地方：
　　1、中断服务程序中修改的供其它程序检测的变量需要加volatile；
　　2、多任务环境下各任务间共享的标志应该加volatile；
　　3、存储器映射的硬件寄存器通常也要加volatile说明，因为每次对它的读写都可能有不同意义；
　　使用该关键字的例子如下：

volatile int i=10;   
int a = i;     
int b = i;  //其他代码，并未明确告诉编译器，对i进行过操作  

volatile 指出 i是随时可能发生变化的，每次使用它的时候必须从i的地址中读取，因而编译器生成的汇编代码会重新从i的地址读取数据放在b中。而优化做法是，由于编译器发现两次从i读数据的代码之间的代码没有对i进行过操作，它会自动把上次读的数据(即10)放在b中，而不是重新从i里面读。这样以来，如果i是一个寄存器变量或者表示一个端口数据就容易出错，所以说volatile可以保证对特殊地址的直接访问。

//addr为volatile变量  
addr=0x57;   
addr=0x58;  

如果上述两条语句是对外部硬件执行不同的操作,那么编译器就不能像对待普通的程序那样对上述语句进行优化只认为“addr=0x58;”而忽略第一条语句(即只产生一条机器代码),此时编译器会逐一的进行编译并产生相应的机器代码(两条)。
　　volatile总是与优化有关，编译器有一种技术叫做数据流分析，分析程序中的变量在哪里赋值、在哪里使用、在哪里失效，分析结果可以用于常量合并，常量传播等优化，进一步可以死代码消除。但有时这些优化不是程序所需要的，这时可以用volatile关键字禁止做这些优化，它有下面的作用：
　　1、不会在两个操作之间把volatile变量缓存在寄存器中。在多任务、中断等环境下，变量可能被其他的程序改变，编译器自己无法知道，volatile就是告诉编译器这种情况。
　　2、不做常量合并、常量传播等优化，所以像下面的代码，if的条件不会当作无条件真。

volatile int i = 1;   
if (i > 0)  
   ...   

3、对volatile变量的读写不会被优化掉。如果你对一个变量赋值但后面没用到，编译器常常可以省略那个赋值操作，然而对Memory Mapped IO的处理是不能这样优化的。

3、volatile关键字的作用、原理

在只有双重检查锁，没有volatile的懒加载单例模式中，由于指令重排序的问题，我确实不会拿到两个不同的单例了，但我会拿到 “半个”单例。

而发挥神奇作用的volatile，可以当之无愧的被称为Java并发编程中“出现频率最高的关键字”，常用于保持内存可见性和防止指令重排序。

保持内存可见性

内存可见性（Memory Visibility）：所有线程都能看到共享内存的最新状态。

失效数据
以下是一个简单的可变整数类：

public class MutableInteger {
	private int value;
	public int get(){
		return value;
	}
	public void set(int value){
		this.value = value;
	}
}

MutableInteger不是线程安全的，因为get和set方法都是在没有同步的情况下进行的。如果线程1调用了set方法，那么正在调用的get的线程2可能会看到更新后的value值，也可能看不到。

解决方法很简单，将value声明为volatile变量：

private volatile int value;

神奇的volatile关键字
神奇的volatile关键字解决了神奇的失效数据问题。

Java变量的读写
Java通过几种原子操作完成工作内存和主内存的交互：

1. lock：作用于主内存，把变量标识为线程独占状态。
2. unlock：作用于主内存，解除独占状态。
3. read：作用主内存，把一个变量的值从主内存传输到线程的工作内存。
4. load：作用于工作内存，把read操作传过来的变量值放入工作内存的变量副本中。
5. use：作用工作内存，把工作内存当中的一个变量值传给执行引擎。
6. assign：作用工作内存，把一个从执行引擎接收到的值赋值给工作内存的变量。
7. store：作用于工作内存的变量，把工作内存的一个变量的值传送到主内存中。
8. write：作用于主内存的变量，把store操作传来的变量的值放入主内存的变量中。

volatile如何保持内存可见性
volatile的特殊规则就是：

• read、load、use动作必须连续出现。
• assign、store、write动作必须连续出现。

所以，使用volatile变量能够保证:

• 每次读取前必须先从主内存刷新最新的值。
• 每次写入后必须立即同步回主内存当中。
  也就是说，volatile关键字修饰的变量看到的随时是自己的最新值。线程1中对变量v的最新修改，对线程2是可见的。

防止指令重排
在基于偏序关系的Happens-Before内存模型中，指令重排技术大大提高了程序执行效率，但同时也引入了一些问题。

一个指令重排的问题——被部分初始化的对象
懒加载单例模式和竞态条件
一个懒加载的单例模式实现如下：

class Singleton {
	private static Singleton instance;
	private Singleton(){}
	public static Singleton getInstance() {
		if ( instance == null ) { //这里存在竞态条件
			instance = new Singleton();
		}
		return instance;
	}
}

竞态条件会导致instance引用被多次赋值，使用户得到两个不同的单例。

DCL和被部分初始化的对象
为了解决这个问题，可以使用synchronized关键字将getInstance方法改为同步方法；但这样串行化的单例是不能忍的。所以我猿族前辈设计了DCL（Double Check Lock，双重检查锁） 机制，使得大部分请求都不会进入阻塞代码块：

class Singleton {
	private static Singleton instance;
	private Singleton(){}
	public static Singleton getInstance() {
		if ( instance == null ) { //当instance不为null时，仍可能指向一个“被部分初始化的对象”
			synchronized (Singleton.class) {
				if ( instance == null ) {
					instance = new Singleton();
				}
			}
		}
		return instance;
	}
}

“看起来”非常完美：既减少了阻塞，又避免了竞态条件。不错，但实际上仍然存在一个问题——当instance不为null时，仍可能指向一个"被部分初始化的对象"。

问题出在这行简单的赋值语句：

instance = new Singleton();

它并不是一个原子操作。事实上，它可以”抽象“为下面几条JVM指令：

memory = allocate();	//1：分配对象的内存空间
initInstance(memory);	//2：初始化对象
instance = memory;		//3：设置instance指向刚分配的内存地址

上面操作2依赖于操作1，但是操作3并不依赖于操作2，所以JVM可以以“优化”为目的对它们进行重排序，经过重排序后如下：

memory = allocate();	//1：分配对象的内存空间
instance = memory;		//3：设置instance指向刚分配的内存地址（此时对象还未初始化）
ctorInstance(memory);	//2：初始化对象

可以看到指令重排之后，操作 3 排在了操作 2 之前，即引用instance指向内存memory时，这段崭新的内存还没有初始化——即，引用instance指向了一个"被部分初始化的对象"。此时，如果另一个线程调用getInstance方法，由于instance已经指向了一块内存空间，从而if条件判为false，方法返回instance引用，用户得到了没有完成初始化的“半个”单例。
解决这个该问题，只需要将instance声明为volatile变量：

private static volatile Singleton instance;

也就是说，在只有DCL没有volatile的懒加载单例模式中，仍然存在着并发陷阱。我确实不会拿到两个不同的单例了，但我会拿到 “半个”单例 （未完成初始化）。
然而，许多面试书籍中，涉及懒加载的单例模式最多深入到DCL，却只字不提volatile。这“看似聪明”的机制，曾经被我广大初入Java世界的猿胞大加吹捧——我在大四实习面试跟谁学的时候，也得意洋洋的从饱汉、饿汉讲到Double
Check，现在看来真是傻逼。对于考查并发的面试官而言，单例模式的实现就是一个很好的切入点，看似考查设计模式，其实期望你从设计模式答到并发和内存模型。

volatile如何防止指令重排
volatile关键字通过 “内存屏障” 来防止指令被重排序。

为了实现volatile的内存语义，编译器在生成字节码时，会在指令序列中插入内存屏障来禁止特定类型的处理器重排序。然而，对于编译器来说，发现一个最优布置来最小化插入屏障的总数几乎不可能，为此，Java内存模型采取保守策略。

下面是基于保守策略的JMM内存屏障插入策略：

• 在每个volatile写操作的前面插入一个StoreStore屏障。
• 在每个volatile写操作的后面插入一个StoreLoad屏障。
• 在每个volatile读操作的前面插入一个LoadLoad屏障。
• 在每个volatile读操作的后面插入一个LoadStore屏障。

进阶
在一次回答上述问题时，忘记了解释一个很容易引起疑惑的问题：

如果存在这种重排序问题，那么synchronized代码块内部不是也可能出现相同的问题吗？

即这种情况：

class Singleton {
	...
		if ( instance == null ) { //可能发生不期望的指令重排
			synchronized (Singleton.class) {
				if ( instance == null ) {
					instance = new Singleton();
					System.out.println(instance.toString()); //程序顺序规则发挥效力的地方
				}
			}
		}
	...
}

难道调用 instance.toString() 方法时，instance也可能未完成初始化吗？

首先还请放宽心，synchronized代码块内部虽然会重排序，但不会在代码块的范围内导致线程安全问题。

Happens-Before内存模型和程序顺序规则

程序顺序规则：如果程序中操作A在操作B之前，那么线程中操作A将在操作B之前执行。

前面说过，只有在Happens-Before内存模型中才会出现这样的指令重排序问题。Happens-Before内存模型维护了几种Happens-Before规则，程序顺序规则最基本的规则。程序顺序规则的目标对象是一段程序代码中的两个操作A、B，其保证此处的指令重排不会破坏操作A、B在代码中的先后顺序，但与不同代码甚至不同线程中的顺序无关。

因此，在synchronized代码块内部，instance = new Singleton() 仍然会指令重排序，但重排序之后的所有指令，仍然能够保证在 instance.toString() 之前执行。进一步的，单线程中，if ( instance == null ) 能保证在synchronized代码块之前执行；但多线程中，线程1中的if ( instance == null ) 却与线程2中的synchronized代码块之间没有偏序关系，因此线程2中synchronized代码块内部的指令重排对于线程1是不期望的，导致了此处的并发陷阱。

类似的Happens-Before规则还有volatile变量规则、监视器锁规则等。程序猿可以借助（Piggyback）现有的Happens-Before规则来保持内存可见性和防止指令重排。

注意点
上面简单讲解了volatile关键字的作用和原理，但对volatile的使用过程中很容易出现的一个问题是：

错把volatile变量当做原子变量。

出现这种误解的原因，主要是volatile关键字使变量的读、写具有了“原子性”。然而这种原子性仅限于变量（包括引用）的读和写，无法涵盖变量上的任何操作，即：

• 基本类型的自增（如count++）等操作不是原子的。
• 对象的任何非原子成员调用（包括成员变量和成员方法）不是原子的。
  如果希望上述操作也具有原子性，那么只能采取锁、原子变量更多的措施。

总结
综上，其实volatile保持内存可见性和防止指令重排序的原理，本质上是同一个问题，也都依靠内存屏障得到解决。