volatile说明

本文简叙：

1.诡异的死循环

2.java内存模型简述及JMM对volatile变量定义的特殊规则

3.通过与synchronized对比来进一步说明volatile作用

一：诡异的死循环

在说volatile之前，先来个小例子来引入今天得话题。

 

图1

   如图1，在eclipse jdk764位环境下执行以上代码会出现诡异得死循环。结果如右图所示。看今天得话题也知道只要在4行代码处添加volatile关键字就能解决这死循环问题（可以自己实验下，此处就不贴出了）。是什么原因造成得这个现象呢？

    在第9行出执行setIsFlag 方法，在第10行处也的确输出isFlag为 false，然而意外的是代码却卡在了22行循环处，要知道这里为什么会这样我们还得先说说java内存模型。

二:java内存模型简述及JMM对volatile变量定义的特殊规则

            Java内存模型简称JMM（Java Memory Model），是Java虚拟机所定义的一种抽象规范，用来屏蔽不同硬件和操作系统的内存访问差异，让java程序在各种平台下都能达到一致的内存访问效果。JMM长什么样呢，如下图。

            Java内存模型的主要目标是定义Java内存中各个变量的访问规则，即在虚拟机中把变量存入内存和在内存中取出变量这样的底层细节。此处的变量与java编程所说的变量有所区别，它包括实例字段，静态字段和构成数组对象的元素，不包括局部变量和方法参数。后者是线程私有的不存在共享问题，自然也就不存在竞争问题（此处应注意区分概念，如果局部变量是一个reference（引用）类型，它引用的对象存在堆中是可以被各个线程所共享的，而reference本身是在java栈的局部变量表中，它是线程私有的）。

    从抽象角度看，JMM定义了java线程和主线程之间的抽象关系：线程之间的共享变量存储在主内存，每一个线程都有一个私有的本地内存，本地内存中存储了以读/写共享变量的副本（这里值得注意的是，要是一个共享变量为对象，并不会把整个对象在copy一份，这个对象的引用，对象中的某个字段有可能会被拷贝一份）。本地内存时抽象的一个概念，并不真实存在。它涵盖了缓存,写缓冲，寄存器以及其他的硬件和编译器的优化。

            Java内存模型并没有限制执行引擎使用处理器的特点寄存器或缓存来和主内存进行交互，也没有限制即时编译器惊喜调整代码执行顺序这类优化措施。

            关于主内存与工作内存之间的交互协议，即一个变量如何从主内存拷贝到工作内存。如何从工作内存同步到主内存中的实现细节。java内存模型定义了8种操作来完成。这8种操作每一种都是原子操作。8种操作如下：

· lock(锁定)：作用于主内存，它把一个变量标记为一条线程独占状态；

· unlock(解锁)：作用于主内存，它将一个处于锁定状态的变量释放出来，释放后的变量才能够被其他线程锁定；

· read(读取)：作用于主内存，它把变量值从主内存传送到线程的工作内存中，以便随后的load动作使用；

· load(载入)：作用于工作内存，它把read操作的值放入工作内存中的变量副本中；

· use(使用)：作用于工作内存，它把工作内存中的值传递给执行引擎，每当虚拟机遇到一个需要使用这个变量的指令时候，将会执行这个动作；

· assign(赋值)：作用于工作内存，它把从执行引擎获取的值赋值给工作内存中的变量，每当虚拟机遇到一个给变量赋值的指令时候，执行该操作；

· store(存储)：作用于工作内存，它把工作内存中的一个变量传送给主内存中，以备随后的write操作使用；

· write(写入)：作用于主内存，它把store传送值放到主内存中的变量中。

Java内存模型还规定了执行上述8种基本操作时必须满足如下规则:

   1 · 不允许read和load、store和write操作之一单独出现，以上两个操作必须按顺序执行，但没有保证必须连续执行，也就是说，read与load之间、store与write之间是可插入其他指令的。

   2· 不允许一个线程丢弃它的最近的assign操作，即变量在工作内存中改变了之后必须把该变化同步回主内存。

   3 · 不允许一个线程无原因地（没有发生过任何assign操作）把数据从线程的工作内存同步回主内存中。

   4 · 一个新的变量只能从主内存中“诞生”，不允许在工作内存中直接使用一个未被初始化（load或assign）的变量，换句话说就是对一个变量实施use和store操作之前，必须先执行过了assign和load操作。

   5 · 一个变量在同一个时刻只允许一条线程对其执行lock操作，但lock操作可以被同一个条线程重复执行多次，多次执行lock后，只有执行相同次数的unlock操作，变量才会被解锁。

    6· 如果对一个变量执行lock操作，将会清空工作内存中此变量的值，在执行引擎使用这个变量前，需要重新执行load或assign操作初始化变量的值。

    7· 如果一个变量实现没有被lock操作锁定，则不允许对它执行unlock操作，也不允许去unlock一个被其他线程锁定的变量。

    8· 对一个变量执行unlock操作之前，必须先把此变量同步回主内存（执行store和write操作）。

    我们来说下java内存模型对volatile变量定义的特殊规则。假定T表示一个线程，v和w分别表示两个volatile型变量，那么在进行read/load/use/assign/store/write操作时需要满足如下规则（来自深入理解java虚拟机）：

1. 只有当线程T对变量V执行的前一个动作是load的时候，线程T才能对变量V执行use动作，并且，只有当线程T对变量V执行的后一个动作是use的时候，线程T才能对变量V执行load动作。线程T对变量V的use动作可以认为是和线程T对变量V的load/read动作相关联，必须连续一起出现（这条规则要求在工作内存中，每次使用V前都必须先从主内存刷新最新的值，用于保证能看见其他线程对变量V所做的修改后的值。这条翻译下就是read->load->use 这几个指令以原子形式执行）。

2. 只有当线程T对变量V执行的前一个动作的是assign的时候，线程T才能对变量V执行store动作；并且，只有当线程T对变量V执行的后一个动作是store的时候，线程T才能对变量V执行assign动作。线程T对变量V的assign动作可以认为是和线程T对变量V的store，write动作相关联，必须联系一起出现（这条规则要求在工作内存中，每次修改V后都必须立刻同步回主内存中，用于保证其他线程可以看到自己对变量V所做的修改。这条翻译下就是 assign->store->write 这几个指令以原子的形式执行）注：综合1，2条可以通俗的理解成JMM把本地内存设成为无效。

3.假定动作A是线程T对变量V实施的use或assign动作，假定动作F是和动作A相关联的load或store动作，假定动作P是和动作F相应的对应变量V的read或write动作；类似的，假定动作B是线程T对变量W实施的use或assign动作，假定动作G是和动作B相关联的load或store动作，假定动作Q是和动作G想要的对变量W的read或write动作。如果A先于B，那么P先于Q（这条规则要求volatile修饰的变量不会被指令重排序优化，保证代码的执行顺序与程序的顺序相同。这条请忽略，太绕口了，下文会详细讲volatile对重排序的影响）

絮絮叨叨一大堆，但是内存模型又是不可回避的话题。现在回到刚才死循环的问题，在启动RunThread线程后，该线程把public static boolean isFlag = true读取到该线程的本地内存中，然后while每次循环读取的值都是在自己的本地内存中取得isFlag=true，即便是主线程更改了主内存中的isFlag 值，所以该线程死循环了。这个问题其实就是私有堆栈的值和公共堆栈中的值不同步造成的。解决该问题的办法就是用volatile声明isFlag。基本都知道volatile有两个功能：保证内存可见性（强制从主内存读值），禁止指令重拍。这里就是用到它的保证内存的可见性，在isflag声明为volatile后上文中的RunThread线程在每次while循环的时候就会直接去主内存读值。

其实这里基本就把volatile第一个作用基本介绍差不多了（保证内存可见性）。不过只是介绍到这估计不少同学会蒙蔽来，蒙蔽着去~~

三.通过与synchronized对比来进一步说明volatile作用

synchronized这个关键字相信大家都相对熟悉，并且相信不少同学会把这两个关键字混肴。为了更好的理解volatile这里就说下synchronized和volatile的不同：

1. 关键字volatile性能别synchronized好，并且volatile只能修饰变量，而synchronized可以修饰方法，代码块。

2. 多线程下volatile不会发生阻塞，而synchronized会。

3. Volatile能保证数据的可见性，但不能保证原子性；而synchronized可以保证原子性并间接的保证可见性。

为了更直白的的来说明volatile，下面通过具体的代码实例来说明Volatile的作用及与synchronized的区别

 

假设有多个线程调用上面三个方法，这个程序在语意上和下面等价。

 

如上面实例程序所示，一个volatile变量的单个读/写操作，与一个普通变量的读/写操作都是使用同一个锁来同步，它们之间执行效果相同。

简而言之，volatile变量自身具有下列特性：

1. 可见性。对一个volatile变量的读，总是能看到（任意线程）对这个volatile变量最后的写入。

2. 原子性。对任意单个volatile变量的读/写具有原子性，但类似于volatile++这种复合操作不具有原子性。

让我们从内存方面进一步的来分析下在多线程环境下像volatile int count=；count++ 这种操作为什么不是原子性的。见下图

 

上图中，操作2不是原子操作（原因见上文，JMM对volatile声明的变量只保证了操作1和操作3的原子性），并且这一步在多线程中是多次出现的，比如线程1在执行操作2，而线程2又去读了主线程的count或者线程2已经执行完操作3把主内存中的count值覆盖了等等。。这样都会出现问题的。volatile变量只保证了从内存中读的值是最新值（具体原因上文多次讲到），并不能保证一个变量复合操作的原子性，所以一个变量的复合操作还是用同步锁吧。

写在这一小结的后边：对于引用型 volatile 变量， volatile 关键字只是保证读线程能够读取到个指向对象的相对新的内存地址（引用），而这个内存地址指向的对象的实例/静态变量值是否是相对新的则没有保障。

ps:文中内容大部分参考自<<深入理解java虚拟机（第二版）>>，<<java并发编程艺术>>，<<Java多线程编程实战指南 核心篇>>，<<Java多线程编程核心技术>>几本书，有兴趣的小伙伴可以直接翻阅原书。

转载请表明出处：https://blog.csdn.net/qq_31387317/article/details/80449467