- Java volatile原理
- 定义
- volatile变量具备两种特性
- 内存语义
- 写的内存语义
- 读的内存语义
- volatile实现的原理
- 可见性
- 有序性
- volatile 的应用场景
- 模式1：状态标志
- 模式2：一次性安全发布(one-time safe publication)
- 模式3：独立观察(independent observation)
- 模式4：volatile bean 模式
- 模式5：开销较低的读－写锁策略
- 模式6：双重检查(double-checked)
JAVA编程语言允许线程访问共享变量，为了确保共享变量能被准确和一致的更新，线程应该使用排他锁单独获取这个变量。
volatile变量具备两种特性- 对所有线程可见，在一个线程修改了变量的值之后，新的值其他的线程是可以立即获取的。针对的可见性
- 禁止指令重排，即不会被缓存在寄存器或者对其他处理器不可见的地方。针对的有序性
volatile将变量的读取变为直接在主内存的方式进行读取，是一个共享的内存。不是各个线程单独开辟内存空间。
volatile不是完全安全的（原子性），只有在满足以下条件才是安全的。（缓存行大小的问题）
- 对变量的写操作不依赖当前值，只是单纯的赋值（boolean flag =true）或者64位long型
- 不同的变量不能相互依赖
当写一个volatile变量时，JMM会把线程对应的本地内存中的共享变量值刷新到主内存。
读的内存语义当读一个volatile变量时，JMM会把线程对应的本地内存置为无效，线程接下来从主内存中读取共享变量。
volatile实现的原理 可见性-
Lock前缀指令会引起处理器缓存回写到内存
volatile修饰的变量在转成汇编语言的时候会多出lock前缀的指令。LOCK前缀指令会在处理器执行指令期间声言处理器的LOCK#信号。早多核的环境中LOCK#信号可以确保在声言该信号期间，处理器可以独占任何共享缓存。在在过去的Inetl486和奔腾的处理器中，在总线上进行声言LOCK#信号来完成锁操作。锁住总线后，其他CPU就不能访问总线，也就不能访问内存。但是在P6和现在的处理器中，它会锁定内存区域并回写到内存，并使用缓存一致性机制来确保修改操作的原子性。此操作称为“缓存锁定”。缓存一致性机制会阻止同时修改由两个以上处理器缓存的内存区域的数据。
-
一个处理器的缓存回写到内存会导致其他处理器的缓存无效
IA-32处理器和Intel64处理器使用MESI(修改、独占、共享、无效)控制协议去维护内部缓存和其他处理器缓存的一致性。在多核处理器系统中进行操作的时候，可以嗅探到其他处理器访问系统内存和它们的内部缓存。这里的嗅探技术可以保存它的内部缓存、系统内存和其他处理器的缓存的数据在总线上保持一致。
volatile 的 happens-before 关系
hapens-before的规则中有一条关于volatile的，对一个 volatile 变量的写操作先行发生于后面对这个变量的读操作。
//假设线程A执行writer方法，线程B执行reader方法
class VolatileExample {
int a = 0;
volatile boolean flag = false;
public void writer() {
a = 1; // 1 线程A修改共享变量
flag = true; // 2 线程A写volatile变量
}
public void reader() {
if (flag) { // 3 线程B读同一个volatile变量
int i = a; // 4 线程B读共享变量
……
}
}
}
根据 happens-before 规则，上面过程会建立 3 类 happens-before 关系。 
- 黑色箭头实线代表根据程序次序规则：1 happens-before 2 且 3 happens-before 4。
- 红色箭头实线代表根据 volatile 规则：2 happens-before 3。
- 蓝色箭头实线代表根据 happens-before 的传递性规则：1 happens-before 4。
根据上述规则，线程A在修改volatile的变量flag为true时，线程B可以快速感知，并在执行读取同一个volatile变量flag时，正确获取true。
JMM 提供了内存屏障阻止重排序。
为了性能优化，JMM 在不改变正确语义的前提下，会允许编译器和处理器对指令序列进行重排序。JMM 提供了内存屏障阻止这种重排序。
JMM 会针对编译器制定 volatile 重排序规则表。 
NO表示禁止重排序。
为了实现 volatile 内存语义时，编译器在生成字节码时，会在指令序列中插入内存屏障来禁止特定类型的处理器重排序。
对于编译器来说，发现一个最优布置来最小化插入屏障的总数几乎是不可能的，为此，JMM 采取了保守的策略。
-
在每个 volatile 写操作的前面插入一个 StoreStore 屏障。
-
在每个 volatile 写操作的后面插入一个 StoreLoad 屏障。
-
在每个 volatile 读操作的后面插入一个 LoadLoad 屏障。
-
在每个 volatile 读操作的后面插入一个 LoadStore 屏障。
volatile 写是在前面和后面分别插入内存屏障，而 volatile 读操作是在后面插入两个内存屏障。
内存屏障说明StoreStore 屏障禁止上面的普通写和下面的 volatile 写重排序。StoreLoad 屏障防止上面的 volatile 写与下面可能有的 volatile 读/写重排序。LoadLoad 屏障禁止下面所有的普通读操作和上面的 volatile 读重排序。LoadStore 屏障禁止下面所有的普通写操作和上面的 volatile 读重排序。保守策略下，volatile写插入内存屏障后生成的实例序列示意图 
保守策略下，volatile读插入内存屏障后生成的实例序列示意图 
public class VolatileBarrierExample {
int a;
volatile int v1 = 1;
volatile int v2 = 2;
void readAndWrite() {
int i = v1;
int j = v2;
a = i + j;
v1 = i + 1;
v2 = j * 2;
}
}
保守策略下，volatile读写插入内存屏障后生成的实例序列示意图 
使用 volatile 必须具备的条件
- 对变量的写操作不依赖于当前值。
- 该变量没有包含在具有其他变量的不变式中。
- 只有在状态真正独立于程序内其他内容时才能使用 volatile。
也许实现 volatile 变量的规范使用仅仅是使用一个布尔状态标志，用于指示发生了一个重要的一次性事件，例如完成初始化或请求停机。
volatile boolean shutdownRequested;
......
public void shutdown() { shutdownRequested = true; }
public void doWork() {
while (!shutdownRequested) {
// do stuff
}
}
缺乏同步会导致无法实现可见性，这使得确定何时写入对象引用而不是原始值变得更加困难。在缺乏同步的情况下，可能会遇到某个对象引用的更新值(由另一个线程写入)和该对象状态的旧值同时存在。(这就是造成著名的双重检查锁定(double-checked-locking)问题的根源，其中对象引用在没有同步的情况下进行读操作，产生的问题是您可能会看到一个更新的引用，但是仍然会通过该引用看到不完全构造的对象)
public class BackgroundFloobleLoader {
public volatile Flooble theFlooble;
public void initInBackground() {
// do lots of stuff
theFlooble = new Flooble(); // this is the only write to theFlooble
}
}
public class SomeOtherClass {
public void doWork() {
while (true) {
// do some stuff...
// use the Flooble, but only if it is ready
if (floobleLoader.theFlooble != null)
doSomething(floobleLoader.theFlooble);
}
}
}
安全使用 volatile 的另一种简单模式是定期 发布 观察结果供程序内部使用。例如，假设有一种环境传感器能够感觉环境温度。一个后台线程可能会每隔几秒读取一次该传感器，并更新包含当前文档的 volatile 变量。然后，其他线程可以读取这个变量，从而随时能够看到最新的温度值。
public class UserManager {
public volatile String lastUser;
public boolean authenticate(String user, String password) {
boolean valid = passwordIsValid(user, password);
if (valid) {
User u = new User();
activeUsers.add(u);
lastUser = user;
}
return valid;
}
}
在 volatile bean 模式中，JavaBean 的所有数据成员都是 volatile 类型的，并且 getter 和 setter 方法必须非常普通 —— 除了获取或设置相应的属性外，不能包含任何逻辑。此外，对于对象引用的数据成员，引用的对象必须是有效不可变的。(这将禁止具有数组值的属性，因为当数组引用被声明为 volatile 时，只有引用而不是数组本身具有 volatile 语义)。对于任何 volatile 变量，不变式或约束都不能包含 JavaBean 属性。
@ThreadSafe
public class Person {
private volatile String firstName;
private volatile String lastName;
private volatile int age;
public String getFirstName() { return firstName; }
public String getLastName() { return lastName; }
public int getAge() { return age; }
public void setFirstName(String firstName) {
this.firstName = firstName;
}
public void setLastName(String lastName) {
this.lastName = lastName;
}
public void setAge(int age) {
this.age = age;
}
}
volatile 的功能还不足以实现计数器。因为 ++x 实际上是三种操作(读、添加、存储)的简单组合，如果多个线程凑巧试图同时对 volatile 计数器执行增量操作，那么它的更新值有可能会丢失。 如果读操作远远超过写操作，可以结合使用内部锁和 volatile 变量来减少公共代码路径的开销。 安全的计数器使用 synchronized 确保增量操作是原子的，并使用 volatile 保证当前结果的可见性。如果更新不频繁的话，该方法可实现更好的性能，因为读路径的开销仅仅涉及 volatile 读操作，这通常要优于一个无竞争的锁获取的开销。
@ThreadSafe
public class CheesyCounter {
// Employs the cheap read-write lock trick
// All mutative operations MUST be done with the 'this' lock held
@GuardedBy("this") private volatile int value;
public int getValue() { return value; }
public synchronized int increment() {
return value++;
}
}
单例模式的一种实现方式，但很多人会忽略 volatile 关键字，因为没有该关键字，程序也可以很好的运行，只不过代码的稳定性总不是 100%，说不定在未来的某个时刻，隐藏的 bug 就出来了。
class Singleton {
private volatile static Singleton instance;
private Singleton() {
}
public static Singleton getInstance() {
if (instance == null) {
syschronized(Singleton.class) {
if (instance == null) {
instance = new Singleton();
}
}
}
return instance;
}
}
主要来自《Java并发编程的艺术》 方腾飞 魏鹏 程晓明版
由于处理器的L1、L2、L3缓存的高速缓存行不支持部分填充行，也就是说如果一个队列不足64字节的话（以L1,L2,L3高速缓存行的大小64byte的CPU为例），那么它的队头和队尾都在同一个缓存行中。JDK7和JDK8中都有针对缓存行填充的优化。
