volatile

说明

volatile是一个类型修饰符。作为指令关键字，确保本条指令不会因编译器的优化而省略。

其主要设计目的是为了java并发线程（多线程）之间的通信。

线程之间的通信

线程的通信是指线程之间以何种机制来交换信息。在编程中，线程之间的通信机制有两种：共享内存和消息传递。

1. 在共享内存的并发模型里，线程之间共享程序的公共状态，线程之间通过写-读内存中的公共状态来隐式进行通信，典型的共享内存通信方式就是通过共享对象进行通信。
2. 在消息传递的并发模型里，线程之间没有公共状态，线程之间必须通过明确的发送消息来显式进行通信，在java中典型的消息传递方式就是wait()和notify()。

线程间的同步

同步是指程序用于控制不同线程之间操作发生相对顺序的机制。

1. 在共享内存并发模型里，同步是显式进行的。程序员必须显式指定某个方法或某段代码需要在线程之间互斥执行。
2. 在消息传递的并发模型里，由于消息的发送必须在消息的接收之前，因此同步是隐式进行的

volatile特性

• 实现可见性：保证了不同线程对这个变量进行操作时的可见性，即一个线程修改了某个变量的值，这新值对其它线程来说是立即可见的。
• 实现有序性：禁止进行指令重排序。
• volatile只能保证对单词读/写的原子性。i++这种操作不能保证原子性

可见性

如果是多线程要同时访问同一个变量呢？内存中一个变量会存在于多个工作内存（working memory可供操作的内存）中，线程1修改了变量a的值什么时候对线程2可见？此外，编译器或运行时为了效率可以在允许的时候对指令进行重排序，重排序后的执行顺序就与代码不一致了，这样线程2读取某个变量的时候线程1可能还没有进行写入操作呢，虽然代码顺序上写操作是在前面的。这就是可见性问题的由来。

JVM架构图

volatile实现原理

volatile变量的内存可见性是基于内存屏障（memory barrier）实现。

 内存屏障又称为内存栅栏，是一个CPU指令。

在程序运行时，为了提高执行性能，编译器和处理器会对指令进行重排序，JMM 为了保证在不同的编译器和 CPU 上有相同的结果，通过插入特定类型的内存屏障来禁止特定类型的编译器重排序和处理器重排序，插入一条内存屏障会告诉编译器和 CPU：不管什么指令都不能和这条Memory Barrier指令（CPU指令）重排序。

注：JMM（Java Memory Model）Java内存模型，隶属于JVM，多线程环境下，用来处理线程之间的通信。

在JVM内部使用的java内存模型将线程堆栈和堆之间的内存分开

• 线程栈(thread stack):

1. 运行在java虚拟机上的每个线程都有自己的线程堆栈(thread stack)
2. 线程堆栈还包含正在执行的每个方法的所有局部变量,一个线程只能访问它自己的线程堆栈。由线程创建的局部变量对于除创建它的线程之外的所有其他线程都是不可见的。
3. 即使两个线程正在执行完全相同的代码，两个线程仍然会在每个线程堆栈中创建该代码的局部变量,一个线程可能会将一个有限变量的副本传递给另一个线程，但它不能共享原始局部变量本身

• 堆：

1. 堆包含在Java应用程序中创建的所有对象，而不管是不是由线程创建的该对象。
2. 堆中的对象可以被持有对象引用的所有线程访问。当一个线程访问一个对象时，它也可以访问该对象的成员变量。
3. 如果两个线程同时调用同一个对象上的一个方法，它们都可以访问该对象的成员变量，但每个线程都有自己的局部变量副本
4. 堆中的数据是共享的,线程不安全

JVM内存模型中包括：

• 程序计数器：程序计数器是一块很小的内存空间，用于记录下一条要运行的指令。每个线程都需要一个程序计数器，各个线程之中的计数器相互独立，是线程中私有的内存空间
• JVM栈区：JVM栈也是线程私有的内存空间，它和java线程同一时间创建，保存了局部变量、部分结果，并参与方法的调用和返回
• 本地方法栈：本地方法栈和JVM栈的功能相似，JVM栈用于管理Java函数的调用，而本地方法栈用于管理本地方法的调用，但不是由Java实现的，而是由C实现的
• JVM堆区：为所有创建的对象和数组分配内存空间,被JVM中所有的线程共享
• 方法区：也被称为永久区，与堆空间相似，被JVM中所有的线程共享。方法区主要保存的信息是类的元数据，方法区中最为重要的是类的类型信息、常量池、域信息、方法信息，其中运行时常量池就在方法区，对永久区的GC回收，一是GC对永久区常量池的回收;二是永久区对元数据的回收

写一段简单的volatile代码

通过 hsdis 和 jitwatch 工具可以得到编译后的汇编代码

1.lock 前缀的指令在多核处理器下会引发两件事情。

1）将当前处理器缓存行的数据写回到系统内存。

2）写回内存的操作会使在其他 CPU 里缓存了该内存地址的数据无效。

2.为了提高处理速度，处理器不直接和内存进行通信，而是先将系统内存的数据读到内部缓存（L1，L2 或其他）后再进行操作，但操作完不知道何时会写到内存。

3.如果对声明了 volatile 的变量进行写操作，JVM 就会向处理器发送一条 lock 前缀的指令，将这个变量所在缓存行的数据写回到系统内存。

4.为了保证各个处理器的缓存是一致的，实现了缓存一致性协议（MESI），每个处理器通过嗅探(snooping)在总线上传播的数据来检查自己缓存的值是不是过期了，当处理器发现自己缓存行对应的内存地址被修改，就会将当前处理器的缓存行设置成无效状态，当处理器对这个数据进行修改操作的时候，会重新从系统内存中把数据读到处理器缓存里。

所有多核处理器下还会完成：当处理器发现本地缓存失效后，就会从内存中重读该变量数据，即可以获取当前最新值。

5.volatile 变量通过这样的机制就使得每个线程都能获得该变量的最新值。

lock指令

1. 在 Pentium 和早期的 IA-32 处理器中，lock 前缀会使处理器执行当前指令时产生一个 LOCK# 信号，会对总线进行锁定，其它 CPU 对内存的读写请求都会被阻塞，直到锁释放。
2. 后来的处理器，加锁操作是由高速缓存锁代替总线锁来处理。

• 因为锁总线的开销比较大，锁总线期间其他 CPU 没法访问内存。
• 这种场景多缓存的数据一致通过缓存一致性协议（MESI）来保证。

缓存一致性

1. 缓存是分段（line）的，一个段对应一块存储空间，称之为缓存行，它是 CPU 缓存中可分配的最小存储单元，大小 32 字节、64 字节、128 字节不等，这与 CPU 架构有关，通常来说是 64 字节。

• 为了使其行为看起来如同一组缓存那样。因而设计了缓存一致性协议(MESI)。
• 缓存一致性协议有多种，但是日常处理的大多数计算机设备都属于 " 嗅探（snooping）" 协议。

1. LOCK# 因为锁总线效率太低，因此使用了多组缓存。
2. 所有内存的传输都发生在一条共享的总线上，而所有的处理器都能看到这条总线。
3. 缓存本身是独立的，但是内存是共享资源，所有的内存访问都要经过仲裁（同一个指令周期中，只有一个 CPU 缓存可以读写内存）。
4. CPU 缓存不仅仅在做内存传输的时候才与总线打交道，而是不停在嗅探总线上发生的数据交换，跟踪其他缓存在做什么。
5. 当一个缓存代表它所属的处理器去读写内存时，其它处理器都会得到通知，它们以此来使自己的缓存保持同步。

• 只要某个处理器写内存，其它处理器马上知道这块内存在它们的缓存段中已经失效

Volatile应用场景

使用volatile必须具备的条件

• 对变量的写操作不依赖于当前值。
• 该变量没有包含在具有其他变量的不变式中。
• 只有在状态真正独立于程序内其他内容时才能使用 volatile。

模式 #1 状态标志

也许实现 volatile 变量的规范使用仅仅是使用一个布尔状态标志，用于指示发生了一个重要的一次性事件，例如完成初始化或请求停机。

模式 #2 一次性安全发布（one-time safe publication）

缺乏同步会导致无法实现可见性，这使得确定何时写入对象引用而不是原始值变得更加困难。在缺乏同步的情况下，可能会遇到某个对象引用的更新值（由另一个线程写入）和该对象状态的旧值同时存在。（这就是造成著名的双重检查锁定（double-checked-locking）问题的根源，其中对象引用在没有同步的情况下进行读操作，产生的问题是您可能会看到一个更新的引用，但是仍然会通过该引用看到不完全构造的对象）。

模式 #3：独立观察（independent observation）

安全使用 volatile 的另一种简单模式是定期 发布 观察结果供程序内部使用。例如，假设有一种环境传感器能够感觉环境温度。一个后台线程可能会每隔几秒读取一次该传感器，并更新包含当前文档的 volatile 变量。然后，其他线程可以读取这个变量，从而随时能够看到最新的温度值

模式 #4 volatile bean 模式

在 volatile bean 模式中，JavaBean 的所有数据成员都是 volatile 类型的，并且 getter 和 setter 方法必须非常普通 —— 除了获取或设置相应的属性外，不能包含任何逻辑。此外，对于对象引用的数据成员，引用的对象必须是有效不可变的。（这将禁止具有数组值的属性，因为当数组引用被声明为 volatile 时，只有引用而不是数组本身具有 volatile 语义）。对于任何 volatile 变量，不变式或约束都不能包含 JavaBean 属性。

模式 #5 开销较低的读－写锁策略​​​​​​​

1. volatile 的功能还不足以实现计数器。因为 ++x 实际上是三种操作（读、添加、存储）的简单组合，如果多个线程凑巧试图同时对 volatile 计数器执行增量操作，那么它的更新值有可能会丢失。
2. 如果读操作远远超过写操作，可以结合使用内部锁和 volatile 变量来减少公共代码路径的开销。
3. 安全的计数器使用 synchronized 确保增量操作是原子的，并使用 volatile 保证当前结果的可见性。如果更新不频繁的话，该方法可实现更好的性能，因为读路径的开销仅仅涉及 volatile 读操作，这通常要优于一个无竞争的锁获取的开销

​​​​​​​

模式 #6 双重检查（double-checked）

单例模式的一种实现方式，但很多人会忽略 volatile 关键字，因为没有该关键字，程序也可以很好的运行，只不过代码的稳定性总不是 100%，说不定在未来的某个时刻，隐藏的 bug 就出来了

推荐懒加载优雅写法 Initialization on Demand Holder（IODH）