加载中…volatile关键字的使用
(2022-10-08 16:21:17)
标签：
编程语言 |
分类： 资料收藏 |
摘录1：C语言中volatile关键字的作用
一.前言
1.编译器优化介绍：
由于内存访问速度远不及CPU处理速度，为提高机器整体性能，在硬件上引入硬件高速缓存Cache，加速对内存的访问。另外在现代CPU中指令的执行并不一定严格按照顺序执行，没有相关性的指令可以乱序执行，以充分利用CPU的指令流水线，提高执行速度。以上是硬件级别的优化。再看软件一级的优化：一种是在编写代码时由程序员优化，另一种是由编译器进行优化。编译器优化常用的方法有：将内存变量缓存到寄存器；调整指令顺序充分利用CPU指令流水线，常见的是重新排序读写指令。对常规内存进行优化的时候，这些优化是透明的，而且效率很好。由编译器优化或者硬件重新排序引起的问题的解决办法是在从硬件（或者其他处理器）的角度看必须以特定顺序执行的操作之间设置内存屏障（memory barrier），linux 提供了一个宏解决编译器的执行顺序问题。
void Barrier(void)
这个函数通知编译器插入一个内存屏障，但对硬件无效，编译后的代码会把当前CPU寄存器中的所有修改过的数值存入内存，需要这些数据的时候再重新从内存中读出。
2.volatile总是与优化有关，编译器有一种技术叫做数据流分析，分析程序中的变量在哪里赋值、在哪里使用、在哪里失效，分析结果可以用于常量合并，常量传播等优化，进一步可以消除一些代码。但有时这些优化不是程序所需要的，这时可以用volatile关键字禁止做这些优化。
二.volatile详解：
1.volatile的本意是“易变的” 因为访问寄存器要比访问内存单元快的多,所以编译器一般都会作减少存取内存的优化，但有可能会读脏数据。当要求使用volatile声明变量值的时候，系统总是重新从它所在的内存读取数据，即使它前面的指令刚刚从该处读取过数据。精确地说就是，遇到这个关键字声明的变量，编译器对访问该变量的代码就不再进行优化，从而可以提供对特殊地址的稳定访问；如果不使用valatile，则编译器将对所声明的语句进行优化。（简洁的说就是：volatile关键词影响编译器编译的结果，用volatile声明的变量表示该变量随时可能发生变化，与该变量有关的运算，不要进行编译优化，以免出错）
2.看两个事例：
1>告诉compiler不能做任何优化
比如要往某一地址送两指令：
int *ip =...; //设备地址
*ip = 1; //第一个指令
*ip = 2; //第二个指令
以上程序compiler可能做优化而成：
int *ip = ...;
*ip = 2;
结果第一个指令丢失。如果用volatile, compiler就不允许做任何的优化，从而保证程序的原意：
volatile int *ip = ...;
*ip = 1;
*ip = 2;
即使你要compiler做优化，它也不会把两次赋值语句简化为一次。它只能做其它的优化。
2>用volatile定义的变量会在程序外被改变,每次都必须从内存中读取，而不能重复使用放在cache或寄存器中的备份。
例如：
volatile char a;
a=0;
while(!a){
//do some things;
}
doother();
如果没有volatile，doother()不会被执行
3.下面是使用volatile变量的几个场景：
1>中断服务程序中修改的供其它程序检测的变量需要加volatile；
例如:
static int i=0;
int main(void)
{
while (1){
if (i) dosomething();
}
}
void ISR_2(void)
{
}
程序的本意是希望ISR_2中断产生时，在main函数中调用dosomething函数，但是，由于编译器判断在main函数里面没有修改过i，因此可能只执行一次对从i到某寄存器的读操作，然后每次if判断都只使用这个寄存器里面的“i副本”，导致dosomething永远也不会被调用。如果将变量加上volatile修饰，则编译器保证对此变量的读写操作都不会被优化（肯定执行）。此例中i也应该如此说明。
2>多任务环境下各任务间共享的标志应该加volatile
3>存储器映射的硬件寄存器通常也要加voliate，因为每次对它的读写都可能有不同意义。
例如：
假设要对一个设备进行初始化，此设备的某一个寄存器为0xff800000。
int
int
{
}
}
经过编译器优化后，编译器认为前面循环半天都是废话，对最后的结果毫无影响，因为最终只是将output这个指针赋值为9，所以编译器最后给你编译编译的代码结果相当于：
int
{
}
如果你对此外部设备进行初始化的过程是必须是像上面代码一样顺序的对其赋值，显然优化过程并不能达到目的。反之如果你不是对此端口反复写操作，而是反复读操作，其结果是一样的，编译器在优化后，也许你的代码对此地址的读操作只做了一次。然而从代码角度看是没有任何问题的。这时候就该使用volatile通知编译器这个变量是一个不稳定的，在遇到此变量时候不要优化。
例如：
volatile
另外，以上这几种情况经常还要同时考虑数据的完整性（相互关联的几个标志读了一半被打断了重写），在1中可以通过关中断来实现，2中禁止任务调度，3中则只能依靠硬件的良好设计。
4.几个问题
可以的，例如只读的状态寄存器。它是volatile因为它可能被意想不到地改变。它是const因为程序不应该试图去修改它。
2) 一个指针可以是volatile 吗？
可以，当一个中服务子程序修改一个指向一个buffer的指针时。
5.volatile的本质：
1> 编译器的优化
在本次线程内, 当读取一个变量时，为提高存取速度，编译器优化时有时会先把变量读取到一个寄存器中；以后，再取变量值时，就直接从寄存器中取值；当变量值在本线程里改变时，会同时把变量的新值copy到该寄存器中，以便保持一致。
当变量在因别的线程等而改变了值，该寄存器的值不会相应改变，从而造成应用程序读取的值和实际的变量值不一致。
当该寄存器在因别的线程等而改变了值，原变量的值不会改变，从而造成应用程序读取的值和实际的变量值不一致。
2>volatile应该解释为“直接存取原始内存地址”比较合适，“易变的”这种解释简直有点误导人。
6.下面的函数有什么错误：
int square(volatile int *ptr)
{
return *ptr * *ptr;
}
该程序的目的是用来返指针*ptr指向值的平方，但是，由于*ptr指向一个volatile型参数，编译器将产生类似下面的代码：
int square(volatile int *ptr)
{
int a,b;
a = *ptr;
b = *ptr;
return a * b;
}
由于*ptr的值可能被意想不到地该变，因此a和b可能是不同的。结果，这段代码可能返不是你所期望的平方值！正确的代码如下：
long square(volatile int *ptr)
{
int a;
a = *ptr;
return a * a;
}
注意：频繁地使用volatile很可能会增加代码尺寸和降低性能,因此要合理的使用volatile。
————————————————
摘录2：volatile与指针
volatile用在如下的几个地方：
1、中断服务程序中修改的供其它程序检测的变量需要加volatile；
2、多任务环境下各任务间共享的标志应该加volatile；
3、存储器映射的硬件寄存器通常也要加volatile说明，因为每次对它的读写都可能由不同意义；
volatile修饰指针一般用在共享指针上面。
下面代码：
uchar * volatile reg;
行代码里volatile修饰的是reg这个变量。所以这里实际上是定义了一个uchar类型的指针，并且这个指针变量本身是volatile 的。但是指针所指的内容并不是volatile的！在实际使用的时候，编译器对代码中指针变量reg本身的操作不会进行优化，但是对reg所指的内容 reg却会作为non-volatile内容处理，对reg的操作还是会被优化。通常这种写法一般用在对共享指针的声明上，即这个指针变量有可能会被中断等函数修改。将其定义为volatile以后，编译器每次取指针变量的值的时候都会从内存中载入，这样即使这个变量已经被别的程序修改了当前函数用的时候也能得到修改后的值（否则通常只在函数开始取一次放在寄存器里，以后就一直使用寄存器内的副本）。
需要注意将上述代码与下面的代码进行区别
volatile uchar *reg;
这行代码里volatile修饰的是指针所指的内容。所以这里定义了一个uchar类型的指针，并且这个指针指向的是一个volatile的对象。但是指针变量本身并不是volatile的。如果对指针变量reg本身进行计算或者赋值等操作，是可能会被编译器优化的。但是对reg所指向的内容 reg的引用却禁止编译器优化。因为这个指针所指的是一个volatile的对象，所以编译器必须保证对reg的操作都不被优化。通常在驱动程序的开发中，对硬件寄存器指针的定义，都应该采用这种形式。
而
volatile uchar * volatile reg;
这样定义出来的指针就本身是个volatile的变量，又指向了volatile的数据内容。
————————————————
摘录3：volatile关键字的作用和原理
1、volatile关键字的作用
（1）保证变量写操作的可见性；
（2）保证变量前后代码的执行顺序；
2、volatile的底层原理
被volatile修饰的变量被修改时，会将修改后的变量直接写入主存中，并且将其他线程中该变量的缓存置为无效，从而让其它线程对该变量的引用直接从主存中获取数据，这样就保证了变量的可见性。
但是volatile修饰的变量在自增时由于该操作分为读写两个步骤，所以当一个线程的读操作被阻塞时，另一个线程同时也进行了自增操作，此时由于第一个线程的写操作没有进行所以主存中仍旧是之前的原数据，所以当两个线程自增完成后，该变量可能只加了1。因而volatile是无法保证对变量的任何操作都是原子性的。
3、volatile的适用场景
（1）变量的修改不依赖于变量本身
像是i++、i+=这类的操作在多线程下都是不能保证变量的原子性的。
（2）该变量没有包含在具有其他变量的不变式中
————————————————
摘录4：volatile关键字及其作用
本文主要介绍Java语言中的volatile关键字，内容涵盖volatile的保证内存可见性、禁止指令重排等。
1 保证内存可见性
1.1 基本概念
可见性是指线程之间的可见性，一个线程修改的状态对另一个线程是可见的。也就是一个线程修改的结果，另一个线程马上就能看到。
1.2 实现原理
当对非volatile变量进行读写的时候，每个线程先从主内存拷贝变量到CPU缓存中，如果计算机有多个CPU，每个线程可能在不同的CPU上被处理，这意味着每个线程可以拷贝到不同的CPU cache中。
volatile变量不会被缓存在寄存器或者对其他处理器不可见的地方，保证了每次读写变量都从主内存中读，跳过CPU cache这一步。当一个线程修改了这个变量的值，新值对于其他线程是立即得知的。
2 禁止指令重排
2.1 基本概念
指令重排序是JVM为了优化指令、提高程序运行效率，在不影响单线程程序执行结果的前提下，尽可能地提高并行度。指令重排序包括编译器重排序和运行时重排序。
volatile变量禁止指令重排序。针对volatile修饰的变量，在读写操作指令前后会插入内存屏障，指令重排序时不能把后面的指令重排序到内存屏障之前的位置。
示例说明：
double r = 2.1; //(1)
double pi = 3.14;//(2)
double area = pi*r*r;//(3)
虽然代码语句的定义顺序为1->2->3，但是计算顺序1->2->3与2->1->3对结果并无影响，所以编译时和运行时可以根据需要对1、2语句进行重排序。
2.2 指令重排带来的问题
如果一个操作不是原子的，就会给JVM留下重排的机会。
线程A中
{
}
线程B中
{
}
如果线程A中的指令发生了重排序，那么B中很可能就会拿到一个尚未初始化或尚未初始化完成的context,从而引发程序错误。
2.3 禁止指令重排的原理
volatile关键字提供内存屏障的方式来防止指令被重排，编译器在生成字节码文件时，会在指令序列中插入内存屏障来禁止特定类型的处理器重排序。
JVM内存屏障插入策略：
每个volatile写操作的前面插入一个StoreStore屏障；
在每个volatile写操作的后面插入一个StoreLoad屏障；
在每个volatile读操作的后面插入一个LoadLoad屏障；
在每个volatile读操作的后面插入一个LoadStore屏障。
2.4 指令重排在双重锁定单例模式中的影响
基于双重检验的单例模式(懒汉型)
public class Singleton3 {
}
instance= new Singleton()并不是一个原子操作，其实际上可以抽象为下面几条JVM指令：
memory
=allocate();
ctorInstance(memory);
instance
=memory;
上面操作2依赖于操作1，但是操作3并不依赖于操作2。所以JVM是可以针对它们进行指令的优化重排序的，经过重排序后如下：
memory
=allocate();
instance
=memory;
ctorInstance(memory);
指令重排之后，instance指向分配好的内存放在了前面，而这段内存的初始化被排在了后面。在线程A执行这段赋值语句，在初始化分配对象之前就已经将其赋值给instance引用，恰好另一个线程进入方法判断instance引用不为null，然后就将其返回使用，导致出错。
解决办法
用volatile关键字修饰instance变量，使得instance在读、写操作前后都会插入内存屏障，避免重排序。
public class Singleton3 {
}
3 volatile无法保证原子性
由于num++非原子操作，先获取num的值，然后写回新的num，最后新值num++；
A线程和B线程可能同时取了一个相同的值，导致线程不安全。
解决方法：给方法增加一个synchronized关键字，但加synchronized就不需要volatile了。
public class VolatileVisibility {
}
4 适用场景
（1）volatile是轻量级同步机制。在访问volatile变量时不会执行加锁操作，因此也就不会使执行线程阻塞，是一种比synchronized关键字更轻量级的同步机制。
（2）volatile无法同时保证内存可见性和原子性。加锁机制既可以确保可见性又可以确保原子性，而volatile变量只能确保可见性。
（3）volatile不能修饰写入操作依赖当前值的变量。声明为volatile的简单变量如果当前值与该变量以前的值相关，那么volatile关键字不起作用，也就是说如下的表达式都不是原子操作：“count++”、“count = count+1”。
（4）当要访问的变量已在synchronized代码块中，或者为常量时，没必要使用volatile；
（5）volatile屏蔽掉了JVM中必要的代码优化，所以在效率上比较低，因此一定在必要时才使用此关键字。
摘录5：volatile详细解读
1. volatile简介
在上一篇文章中我们深入理解了java关键字，我们知道在java中还有一大神器就是关键volatile，可以说是和synchronized各领风骚，其中奥妙，我们来共同探讨下。
通过上一篇的文章我们了解到synchronized是阻塞式同步，在线程竞争激烈的情况下会升级为重量级锁。而volatile就可以说是java虚拟机提供的最轻量级的同步机制。但它同时不容易被正确理解，也至于在并发编程中很多程序员遇到线程安全的问题就会使用synchronized。java内存模型告诉我们，各个线程会将共享变量从主内存中拷贝到工作内存，然后执行引擎会基于工作内存中的数据进行操作处理。线程在工作内存进行操作后何时会写到主内存中？这个时机对普通变量是没有规定的，而针对volatile修饰的变量给java虚拟机特殊的约定，线程对volatile变量的修改会立刻被其他线程所感知，即不会出现数据脏读的现象，从而保证数据的“可见性”。
现在我们有了一个大概的印象就是：被volatile修饰的变量能够保证每个线程能够获取该变量的最新值，从而避免出现数据脏读的现象。
2. volatile实现原理
volatile是怎样实现了？比如一个很简单的Java代码：
1
|
instance = new Instancce() //instance是volatile变量 |
在生成汇编代码时会在volatile修饰的共享变量进行写操作的时候会多出Lock前缀的指令（具体的大家可以使用一些工具去看一下，这里我就只把结果说出来）。我们想这个Lock指令肯定有神奇的地方，那么Lock前缀的指令在多核处理器下会发现什么事情了？主要有这两个方面的影响：
1.
将当前处理器缓存行的数据写回系统内存；
2. 这个写回内存的操作会使得其他CPU里缓存了该内存地址的数据无效
为了提高处理速度，处理器不直接和内存进行通信，而是先将系统内存的数据读到内部缓存（L1，L2或其他）后再进行操作，但操作完不知道何时会写到内存。如果对声明了volatile的变量进行写操作，JVM就会向处理器发送一条Lock前缀的指令，将这个变量所在缓存行的数据写回到系统内存。但是，就算写回到内存，如果其他处理器缓存的值还是旧的，再执行计算操作就会有问题。所以，在多处理器下，为了保证各个处理器的缓存是一致的，就会实现**缓存一致性**协议，**每个处理器通过嗅探在总线上传播的数据来检查自己缓存的值是不是过期**了，当处理器发现自己缓存行对应的内存地址被修改，就会将当前处理器的缓存行设置成无效状态，当处理器对这个数据进行修改操作的时候，会重新从系统内存中把数据读到处理器缓存里。因此，经过分析我们可以得出如下结论：
1. Lock前缀的指令会引起处理器缓存写回内存；
2. 一个处理器的缓存回写到内存会导致其他处理器的缓存失效；
3. 当处理器发现本地缓存失效后，就会从内存中重读该变量数据，即可以获取当前最新值。
这样针对volatile变量通过这样的机制就使得每个线程都能获得该变量的最新值。
3. volatile的happens-before关系
经过上面的分析，我们已经知道了volatile变量可以通过**缓存一致性协议**保证每个线程都能获得最新值，即满足数据的“可见性”。我们继续延续上一篇分析问题的方式（我一直认为思考问题的方式是属于自己，也才是最重要的，也在不断培养这方面的能力），我一直将并发分析的切入点分为**两个核心，三大性质**。两大核心：JMM内存模型（主内存和工作内存）以及happens-before；三条性质：原子性，可见性，有序性（关于三大性质的总结在以后得文章会和大家共同探讨）。废话不多说，先来看两个核心之一：volatile的happens-before关系。
在六条[happens-before规则](https://juejin.im/post/5ae6d309518825673123fd0e
1
2
3
4
5
6
7
8
9
10
11
12
13
|
public class VolatileExample {
}
|
上面的实例代码对应的happens-before关系如下图所示：
加锁线程A先执行writer方法，然后线程B执行reader方法。图中每一个箭头两个节点就代码一个happens-before关系，黑色的代表根据**程序顺序规则**推导出来，红色的是根据**volatile变量的写happens-before 于任意后续对volatile变量的读**，而蓝色的就是根据传递性规则推导出来的。这里的2 happen-before 3，同样根据happens-before规则定义：如果A happens-before B,则A的执行结果对B可见，并且A的执行顺序先于B的执行顺序，我们可以知道操作2执行结果对操作3来说是可见的，也就是说当线程A将volatile变量 flag更改为true后线程B就能够迅速感知。
4. volatile的内存语义
还是按照**两个核心**的分析方式，分析完happens-before关系后我们现在就来进一步分析volatile的内存语义（按照这种方式去学习，会不会让大家对知识能够把握的更深，而不至于不知所措）。还是以上面的代码为例，假设线程A先执行writer方法，线程B随后执行reader方法，初始时线程的本地内存中flag和a都是初始状态，下图是线程A执行volatile写后的状态图。
当volatile变量写后，线程中本地内存中共享变量就会置为失效的状态，因此线程B再需要读取从主内存中去读取该变量的最新值。下图就展示了线程B读取同一个volatile变量的内存变化示意图。
从横向来看，线程A和线程B之间进行了一次通信，线程A在写volatile变量时，实际上就像是给B发送了一个消息告诉线程B你现在的值都是旧的了，然后线程B读这个volatile变量时就像是接收了线程A刚刚发送的消息。既然是旧的了，那线程B该怎么办了？自然而然就只能去主内存去取啦。
好的，我们现在**两个核心**：happens-before以及内存语义现在已经都了解清楚了。是不是还不过瘾，突然发现原来自己会这么爱学习（微笑脸），那我们下面就再来一点干货----volatile内存语义的实现。
4.1 volatile的内存语义实现
我们都知道，为了性能优化，JMM在不改变正确语义的前提下，会允许编译器和处理器对指令序列进行重排序，那如果想阻止重排序要怎么办了？答案是可以添加内存屏障。
JMM内存屏障分为四类见下图，
java编译器会在生成指令系列时在适当的位置会插入内存屏障指令来禁止特定类型的处理器重排序。为了实现volatile的内存语义，JMM会限制特定类型的编译器和处理器重排序，JMM会针对编译器制定volatile重排序规则表：
"NO"表示禁止重排序。为了实现volatile内存语义时，编译器在生成字节码时，会在指令序列中插入内存屏障来禁止特定类型的**处理器重排序**。对于编译器来说，发现一个最优布置来最小化插入屏障的总数几乎是不可能的，为此，JMM采取了保守策略：
1.
在每个volatile写操作的**前面**插入一个StoreStore屏障；
2. 在每个volatile写操作的**后面**插入一个StoreLoad屏障；
3. 在每个volatile读操作的**后面**插入一个LoadLoad屏障；
4. 在每个volatile读操作的**后面**插入一个LoadStore屏障。
需要注意的是：volatile写是在前面和后面**分别插入内存屏障**，而volatile读操作是在**后面插入两个内存屏障**
**StoreStore屏障**：禁止上面的普通写和下面的volatile写重排序；
**StoreLoad屏障**：防止上面的volatile写与下面可能有的volatile读/写重排序
**LoadLoad屏障**：禁止下面所有的普通读操作和上面的volatile读重排序
**LoadStore屏障**：禁止下面所有的普通写操作和上面的volatile读重排序
下面以两个示意图进行理解，图片摘自相当好的一本书《java并发编程的艺术》。
5. 一个示例
我们现在已经理解volatile的精华了，文章开头的那个问题我想现在我们都能给出答案了。更正后的代码为：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
public class VolatileDemo { } |
注意不同点，现在已经**将isOver设置成了volatile变量**，这样在main线程中将isOver改为了true后，thread的工作内存该变量值就会失效，从而需要再次从主内存中读取该值，现在能够读出isOver最新值为true从而能够结束在thread里的死循环，从而能够顺利停止掉thread线程。现在问题也解决了，知识也学到了：）。
喜欢
0
赠金笔