volatile 订阅
volatile是一个特征修饰符(type specifier).volatile的作用是作为指令关键字,确保本条指令不会因编译器的优化而省略,且要求每次直接读值。volatile的变量是说这变量可能会被意想不到地改变,这样,编译器就不会去假设这个变量的值了。 展开全文
volatile是一个特征修饰符(type specifier).volatile的作用是作为指令关键字,确保本条指令不会因编译器的优化而省略,且要求每次直接读值。volatile的变量是说这变量可能会被意想不到地改变,这样,编译器就不会去假设这个变量的值了。
信息
中文名
易变型变量
属    性
类型修饰符
外文名
volatile
释    义
易变的
词    性
形容词
volatile作用
简单地说就是防止编译器对代码进行优化。比如如下程序:对外部硬件而言,上述四条语句分别表示不同的操作,会产生四种不同的动作,但是编译器却会对上述四条语句进行优化,认为只有XBYTE[2]=0x58(即忽略前三条语句,只产生一条机器代码)。如果键入volatile,则编译器会逐一地进行编译并产生相应的机器代码(产生四条代码)。
收起全文
精华内容
参与话题
问答
  • volatile

    2019-12-01 11:58:50
    1. volatile简介 synchronized是阻塞式同步,在线程竞争激烈的情况下会升级为重量级锁。 而volatile就可以说是java虚拟机提供的最轻量级的同步机制。但它同时不容易被正确理解,也至于在并发编程中很多程序员遇到...

    1. volatile简介

    synchronized是阻塞式同步,在线程竞争激烈的情况下会升级为重量级锁。

    而volatile就可以说是java虚拟机提供的最轻量级的同步机制。但它同时不容易被正确理解,也至于在并发编程中很多程序员遇到线程安全的问题就会使用synchronized。

    各个线程会将共享变量从主内存中拷贝到工作内存,然后执行引擎会基于工作内存中的数据进行操作处理。线程在工作内存进行操作后何时会写到主内存中?这个时机对普通变量是没有规定的,而针对volatile修饰的变量给java虚拟机特殊的约定,线程对volatile变量的修改会立刻被其他线程所感知,即不会出现数据脏读的现象,从而保证数据的“可见性”。

    现在我们有了一个大概的印象就是:被volatile修饰的变量能够保证每个线程能够获取该变量的最新值,从而避免出现数据脏读的现象。

    2. volatile实现原理

    volatile是怎样实现了?比如一个很简单的Java代码:

    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关系。

    在六条happends-before规则中有一条是:**volatile变量规则:对一个volatile域的写,happens-before于任意后续对这个volatile域的读。**下面我们结合具体的代码,我们利用这条规则推导下:

    public class VolatileExample {
        private int a = 0;
        private volatile boolean flag = false;
        public void writer(){
            a = 1;          //1
            flag = true;   //2
        }
        public void reader(){
            if(flag){      //3
                int i = a; //4
            }
        }
    }
    

    上面的实例代码对应的happens-before关系如下图所示:

    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写后的状态图。

    线程A执行volatile写后的内存状态图

    当volatile变量写后,线程中本地内存中共享变量就会置为失效的状态,因此线程B再需要读取从主内存中去读取该变量的最新值。下图就展示了线程B读取同一个volatile变量的内存变化示意图。

    线程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重排序规则表:

    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并发编程的艺术》。

    volatile写插入内存屏障示意图

    volatile读插入内存屏障示意图

    5. 一个示例

    我们现在已经理解volatile的精华了,文章开头的那个问题我想现在我们都能给出答案了。更正后的代码为:

    public class VolatileDemo {
        private static volatile boolean isOver = false;
    
        public static void main(String[] args) {
            Thread thread = new Thread(new Runnable() {
                @Override
                public void run() {
                    while (!isOver) ;
                }
            });
            thread.start();
            try {
                Thread.sleep(500);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            isOver = true;
        }
    }
    

    注意不同点,现在已经将isOver设置成了volatile变量,这样在main线程中将isOver改为了true后,thread的工作内存该变量值就会失效,从而需要再次从主内存中读取该值,现在能够读出isOver最新值为true从而能够结束在thread里的死循环,从而能够顺利停止掉thread线程。现在问题也解决了,知识也学到了:)。

    展开全文
  • Volatile

    千次阅读 2019-05-06 12:30:16
    同synchronized相比(synchronized通常称为重量级锁),volatile更轻量级,相比使用synchronized所带来的庞大开销,倘若能恰当的合理的使用volatile,自然是美事一桩。  为了能比较清晰彻底的理解volatile,我们...

     

    内存可见性

      volatile是Java提供的一种轻量级的同步机制,在并发编程中,它也扮演着比较重要的角色。同synchronized相比(synchronized通常称为重量级锁),volatile更轻量级,相比使用synchronized所带来的庞大开销,倘若能恰当的合理的使用volatile,自然是美事一桩。

      为了能比较清晰彻底的理解volatile,我们一步一步来分析。首先来看看如下代码

    public class TestVolatile {
        boolean status = false;
    
        /**
         * 状态切换为true
         */
        public void changeStatus(){
            status = true;
        }
    
        /**
         * 若状态为true,则running。
         */
        public void run(){
            if(status){
                System.out.println("running....");
            }
        }
    }

     

    上面这个例子,在多线程环境里,假设线程A执行changeStatus()方法后,线程B运行run()方法,可以保证输出"running....."吗?

      答案是NO! 

      这个结论会让人有些疑惑,可以理解。因为倘若在单线程模型里,先运行changeStatus方法,再执行run方法,自然是可以正确输出"running...."的;但是在多线程模型中,是没法做这种保证的。因为对于共享变量status来说,线程A的修改,对于线程B来讲,是"不可见"的。也就是说,线程B此时可能无法观测到status已被修改为true。那么什么是可见性呢?

      所谓可见性,是指当一条线程修改了共享变量的值,新值对于其他线程来说是可以立即得知的。很显然,上述的例子中是没有办法做到内存可见性的。

     

    Java内存模型

      为什么出现这种情况呢,我们需要先了解一下JMM(java内存模型)

      java虚拟机有自己的内存模型(Java Memory Model,JMM),JMM可以屏蔽掉各种硬件和操作系统的内存访问差异,以实现让java程序在各种平台下都能达到一致的内存访问效果。

      JMM决定一个线程对共享变量的写入何时对另一个线程可见,JMM定义了线程和主内存之间的抽象关系:共享变量存储在主内存(Main Memory)中,每个线程都有一个私有的本地内存(Local Memory),本地内存保存了被该线程使用到的主内存的副本拷贝,线程对变量的所有操作都必须在工作内存中进行,而不能直接读写主内存中的变量。这三者之间的交互关系如下

     

    需要注意的是,JMM是个抽象的内存模型,所以所谓的本地内存,主内存都是抽象概念,并不一定就真实的对应cpu缓存和物理内存。当然如果是出于理解的目的,这样对应起来也无不可。

      大概了解了JMM的简单定义后,问题就很容易理解了,对于普通的共享变量来讲,比如我们上文中的status,线程A将其修改为true这个动作发生在线程A的本地内存中,此时还未同步到主内存中去;而线程B缓存了status的初始值false,此时可能没有观测到status的值被修改了,所以就导致了上述的问题。那么这种共享变量在多线程模型中的不可见性如何解决呢?比较粗暴的方式自然就是加锁,但是此处使用synchronized或者Lock这些方式太重量级了,有点炮打蚊子的意思。比较合理的方式其实就是volatile

      volatile具备两种特性,第一就是保证共享变量对所有线程的可见性。将一个共享变量声明为volatile后,会有以下效应:

        1.当写一个volatile变量时,JMM会把该线程对应的本地内存中的变量强制刷新到主内存中去;

        2.这个写会操作会导致其他线程中的缓存无效。

    上面的例子只需将status声明为volatile,即可保证在线程A将其修改为true时,线程B可以立刻得知

    volatile boolean status = false

    留意复合类操作

      但是需要注意的是,我们一直在拿volatile和synchronized做对比,仅仅是因为这两个关键字在某些内存语义上有共通之处,volatile并不能完全替代synchronized,它依然是个轻量级锁,在很多场景下,volatile并不能胜任。看下这个例子:

    package test;
    
    import java.util.concurrent.CountDownLatch;
    
    /**
     * Created by chengxiao on 2017/3/18.
     */
    public class Counter {
        public static volatile int num = 0;
        //使用CountDownLatch来等待计算线程执行完
        static CountDownLatch countDownLatch = new CountDownLatch(30);
        public static void main(String []args) throws InterruptedException {
            //开启30个线程进行累加操作
            for(int i=0;i<30;i++){
                new Thread(){
                    public void run(){
                        for(int j=0;j<10000;j++){
                            num++;//自加操作
                        }
                        countDownLatch.countDown();
                    }
                }.start();
            }
            //等待计算线程执行完
            countDownLatch.await();
            System.out.println(num);
        }
    }

    执行结果:  224291

     

    针对这个示例,一些同学可能会觉得疑惑,如果用volatile修饰的共享变量可以保证可见性,那么结果不应该是300000么?

    问题就出在num++这个操作上,因为num++不是个原子性的操作,而是个复合操作。我们可以简单讲这个操作理解为由这三步组成:

      1.读取

      2.加一

      3.赋值

      所以,在多线程环境下,有可能线程A将num读取到本地内存中,此时其他线程可能已经将num增大了很多,线程A依然对过期的num进行自加,重新写到主存中,最终导致了num的结果不合预期,而是小于30000

    解决num++操作的原子性问题

      针对num++这类复合类的操作,可以使用java并发包中的原子操作类原子操作类是通过循环CAS的方式来保证其原子性的

     

    /**
     * Created by chengxiao on 2017/3/18.
     */
    public class Counter {
      //使用原子操作类
        public static AtomicInteger num = new AtomicInteger(0);
        //使用CountDownLatch来等待计算线程执行完
        static CountDownLatch countDownLatch = new CountDownLatch(30);
        public static void main(String []args) throws InterruptedException {
            //开启30个线程进行累加操作
            for(int i=0;i<30;i++){
                new Thread(){
                    public void run(){
                        for(int j=0;j<10000;j++){
                            num.incrementAndGet();//原子性的num++,通过循环CAS方式
                        }
                        countDownLatch.countDown();
                    }
                }.start();
            }
            //等待计算线程执行完
            countDownLatch.await();
            System.out.println(num);
        }
    }

     

    执行结果

    300000

     

    禁止指令重排序

    volatile还有一个特性:禁止指令重排序优化。

    重排序是指编译器和处理器为了优化程序性能而对指令序列进行排序的一种手段。但是重排序也需要遵守一定规则:

      1.重排序操作不会对存在数据依赖关系的操作进行重排序。

        比如:a=1;b=a; 这个指令序列,由于第二个操作依赖于第一个操作,所以在编译时和处理器运行时这两个操作不会被重排序。

      2.重排序是为了优化性能,但是不管怎么重排序,单线程下程序的执行结果不能被改变

        比如:a=1;b=2;c=a+b这三个操作,第一步(a=1)和第二步(b=2)由于不存在数据依赖关系,所以可能会发生重排序,但是c=a+b这个操作是不会被重排序的,因为需要保证最终的结果一定是c=a+b=3。

      重排序在单线程模式下是一定会保证最终结果的正确性,但是在多线程环境下,问题就出来了,来开个例子,我们对第一个TestVolatile的例子稍稍改进,再增加个共享变量a

    public class TestVolatile {
        int a = 1;
        boolean status = false;
    
        /**
         * 状态切换为true
         */
        public void changeStatus(){
            a = 2;//1
            status = true;//2
        }
    
        /**
         * 若状态为true,则running。
         */
        public void run(){
            if(status){//3
                int b = a+1;//4
                System.out.println(b);
            }
        }
    }

     

     

    假设线程A执行changeStatus后,线程B执行run,我们能保证在4处,b一定等于3么?

      答案依然是无法保证!也有可能b仍然为2。上面我们提到过,为了提供程序并行度,编译器和处理器可能会对指令进行重排序,而上例中的1和2由于不存在数据依赖关系,则有可能会被重排序,先执行status=true再执行a=2。而此时线程B会顺利到达4处,而线程A中a=2这个操作还未被执行,所以b=a+1的结果也有可能依然等于2。

      使用volatile关键字修饰共享变量便可以禁止这种重排序。若用volatile修饰共享变量,在编译时,会在指令序列中插入内存屏障来禁止特定类型的处理器重排序

      volatile禁止指令重排序也有一些规则,简单列举一下:

      1.当第二个操作是voaltile写时,无论第一个操作是什么,都不能进行重排序

      2.当地一个操作是volatile读时,不管第二个操作是什么,都不能进行重排序

      3.当第一个操作是volatile写时,第二个操作是volatile读时,不能进行重排序

    总结:

      简单总结下,volatile是一种轻量级的同步机制,它主要有两个特性:一是保证共享变量对所有线程的可见性;二是禁止指令重排序优化。同时需要注意的是,volatile对于单个的共享变量的读/写具有原子性,但是像num++这种复合操作,volatile无法保证其原子性,当然文中也提出了解决方案,就是使用并发包中的原子操作类,通过循环CAS地方式来保证num++操作的原子性。关于原子操作类,会在后续的文章进行介绍。

     

    作者: dreamcatcher-cx

    出处: <http://www.cnblogs.com/chengxiao/>

    本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在页面明显位置给出原文链接

     

    展开全文
  • volatile关键字

    万次阅读 2019-02-27 15:26:32
    在Java相关的岗位面试中,很多面试官都喜欢考察面试者对Java并发的了解程度,而以volatile关键字作为一个小的切入点,往往可以一问到底,把Java内存模型(JMM),Java并发编程的一些特性都牵扯出来,深入地话还可以...

    人工智能,零基础入门!http://www.captainbed.net/inner

    在Java相关的岗位面试中,很多面试官都喜欢考察面试者对Java并发的了解程度,而以volatile关键字作为一个小的切入点,往往可以一问到底,把Java内存模型(JMM),Java并发编程的一些特性都牵扯出来,深入地话还可以考察JVM底层实现以及操作系统的相关知识。

    下面我们以一次假想的面试过程,来深入了解下volitile关键字吧!

    面试官: Java并发这块了解的怎么样?说说你对volatile关键字的理解

    就我理解的而言,被volatile修饰的共享变量,就具有了以下两点特性:

    1 . 保证了不同线程对该变量操作的内存可见性;

    2 . 禁止指令重排序。

    面试官: 能不能详细说下什么是内存可见性,什么又是重排序呢?

    这个聊起来可就多了,我还是从Java内存模型说起吧。

    Java虚拟机规范试图定义一种Java内存模型(JMM),来屏蔽掉各种硬件和操作系统的内存访问差异,让Java程序在各种平台上都能达到一致的内存访问效果。简单来说,由于CPU执行指令的速度是很快的,但是内存访问的速度就慢了很多,相差的不是一个数量级,所以搞处理器的那群大佬们又在CPU里加了好几层高速缓存。

    在Java内存模型里,对上述的优化又进行了一波抽象。JMM规定所有变量都是存在主存中的,类似于上面提到的普通内存,每个线程又包含自己的工作内存,方便理解就可以看成CPU上的寄存器或者高速缓存。所以线程的操作都是以工作内存为主,它们只能访问自己的工作内存,且工作前后都要把值在同步回主内存。

    这么说得我自己都有些不清楚了,拿张纸画一下:

    在线程执行时,首先会从主存中read变量值,再load到工作内存中的副本中,然后再传给处理器执行,执行完毕后再给工作内存中的副本赋值,随后工作内存再把值传回给主存,主存中的值才更新。

    使用工作内存和主存,虽然加快的速度,但是也带来了一些问题。比如看下面一个例子:

    i = i + 1;

    假设i初值为0,当只有一个线程执行它时,结果肯定得到1,当两个线程执行时,会得到结果2吗?这倒不一定了。可能存在这种情况:

    线程1: load i from 主存 // i = 0
    i + 1 // i = 1
    线程2: load i from主存 // 因为线程1还没将i的值写回主存,所以i还是0
    i + 1 //i = 1
    线程1: save i to 主存
    线程2: save i to 主存

    如果两个线程按照上面的执行流程,那么i最后的值居然是1了。如果最后的写回生效的慢,你再读取i的值,都可能是0,这就是缓存不一致问题。

    下面就要提到你刚才问到的问题了,JMM主要就是围绕着如何在并发过程中如何处理原子性、可见性和有序性这3个特征来建立的,通过解决这三个问题,可以解除缓存不一致的问题。而volatile跟可见性和有序性都有关。

    面试官:那你具体说说这三个特性呢?

    1 . 原子性(Atomicity): Java中,对基本数据类型的读取和赋值操作是原子性操作,所谓原子性操作就是指这些操作是不可中断的,要做一定做完,要么就没有执行。
    比如:

    i = 2;
    j = i;
    i++;
    i = i + 1;

    上面4个操作中,i=2是读取操作,必定是原子性操作,j=i你以为是原子性操作,其实吧,分为两步,一是读取i的值,然后再赋值给j,这就是2步操作了,称不上原子操作,i++i = i + 1其实是等效的,读取i的值,加1,再写回主存,那就是3步操作了。所以上面的举例中,最后的值可能出现多种情况,就是因为满足不了原子性。

    这么说来,只有简单的读取,赋值是原子操作,还只能是用数字赋值,用变量的话还多了一步读取变量值的操作。有个例外是,虚拟机规范中允许对64位数据类型(long和double),分为2次32为的操作来处理,但是最新JDK实现还是实现了原子操作的。

    JMM只实现了基本的原子性,像上面i++那样的操作,必须借助于synchronizedLock来保证整块代码的原子性了。线程在释放锁之前,必然会把i的值刷回到主存的。

    2 . 可见性(Visibility):

    说到可见性,Java就是利用volatile来提供可见性的。
    当一个变量被volatile修饰时,那么对它的修改会立刻刷新到主存,当其它线程需要读取该变量时,会去内存中读取新值。而普通变量则不能保证这一点。

    其实通过synchronized和Lock也能够保证可见性,线程在释放锁之前,会把共享变量值都刷回主存,但是synchronized和Lock的开销都更大。

    3 . 有序性(Ordering)

    JMM是允许编译器和处理器对指令重排序的,但是规定了as-if-serial语义,即不管怎么重排序,程序的执行结果不能改变。比如下面的程序段:

    double pi = 3.14; //A
    double r = 1; //B
    double s= pi * r * r;//C

    上面的语句,可以按照A->B->C执行,结果为3.14,但是也可以按照B->A->C的顺序执行,因为A、B是两句独立的语句,而C则依赖于A、B,所以A、B可以重排序,但是C却不能排到A、B的前面。JMM保证了重排序不会影响到单线程的执行,但是在多线程中却容易出问题。

    比如这样的代码:

    int a = 0;
    bool flag = false;
    
    public void write() {
    a = 2; //1
    flag = true; //2
    }
    
    public void multiply() {
    if (flag) { //3
    int ret = a * a;//4
    }
    
    }

    假如有两个线程执行上述代码段,线程1先执行write,随后线程2再执行multiply,最后ret的值一定是4吗?结果不一定:

    如图所示,write方法里的1和2做了重排序,线程1先对flag赋值为true,随后执行到线程2,ret直接计算出结果,再到线程1,这时候a才赋值为2,很明显迟了一步。

    这时候可以为flag加上volatile关键字,禁止重排序,可以确保程序的“有序性”,也可以上重量级的synchronized和Lock来保证有序性,它们能保证那一块区域里的代码都是一次性执行完毕的。

    另外,JMM具备一些先天的有序性,即不需要通过任何手段就可以保证的有序性,通常称为happens-before原则。<<JSR-133:Java Memory Model and Thread Specification>>定义了如下happens-before规则:

    1、程序顺序规则: 一个线程中的每个操作,happens-before于该线程中的任意后续操作

    2、监视器锁规则:对一个线程的解锁,happens-before于随后对这个线程的加锁

    3、volatile变量规则: 对一个volatile域的写,happens-before于后续对这个volatile域的读

    4、传递性:如果A happens-before B ,且 B happens-before C, 那么 A happens-before C

    5、start()规则: 如果线程A执行操作ThreadB_start()(启动线程B) , 那么A线程的ThreadB_start()happens-before 于B中的任意操作

    6、join()原则: 如果A执行ThreadB.join()并且成功返回,那么线程B中的任意操作happens-before于线程A从ThreadB.join()操作成功返回。

    7、interrupt()原则: 对线程interrupt()方法的调用先行发生于被中断线程代码检测到中断事件的发生,可以通过Thread.interrupted()方法检测是否有中断发生

    8、finalize()原则:一个对象的初始化完成先行发生于它的finalize()方法的开始

    第1条规则程序顺序规则是说在一个线程里,所有的操作都是按顺序的,但是在JMM里其实只要执行结果一样,是允许重排序的,这边的happens-before强调的重点也是单线程执行结果的正确性,但是无法保证多线程也是如此。

    第2条规则监视器规则其实也好理解,就是在加锁之前,确定这个锁之前已经被释放了,才能继续加锁。

    第3条规则,就适用到所讨论的volatile,如果一个线程先去写一个变量,另外一个线程再去读,那么写入操作一定在读操作之前。

    第4条规则,就是happens-before的传递性。

    后面几条就不再一一赘述了。

    面试官:volatile关键字如何满足并发编程的三大特性的?

    那就要重提volatile变量规则: 对一个volatile域的写,happens-before于后续对这个volatile域的读。
    这条再拎出来说,其实就是如果一个变量声明成是volatile的,那么当我读变量时,总是能读到它的最新值,这里最新值是指不管其它哪个线程对该变量做了写操作,都会立刻被更新到主存里,我也能从主存里读到这个刚写入的值。也就是说volatile关键字可以保证可见性以及有序性。

    继续拿上面的一段代码举例:

    int a = 0;
    bool flag = false;
    
    public void write() {
    a = 2; //1
    flag = true; //2
    }
    
    public void multiply() {
    if (flag) { //3
    int ret = a * a;//4
    }
    
    }

    这段代码不仅仅受到重排序的困扰,即使1、2没有重排序。3也不会那么顺利的执行的。假设还是线程1先执行write操作,线程2再执行multiply操作,由于线程1是在工作内存里把flag赋值为1,不一定立刻写回主存,所以线程2执行时,multiply再从主存读flag值,仍然可能为false,那么括号里的语句将不会执行。

    如果改成下面这样:

    int a = 0;
    volatile bool flag = false;
    
    public void write() {
    a = 2; //1
    flag = true; //2
    }
    
    public void multiply() {
    if (flag) { //3
    int ret = a * a;//4
    }
    }

    那么线程1先执行write,线程2再执行multiply。根据happens-before原则,这个过程会满足以下3类规则:

    1、程序顺序规则:1 happens-before 2; 3 happens-before 4; (volatile限制了指令重排序,所以1 在2 之前执行)

    2、volatile规则:2 happens-before 3

    3、传递性规则:1 happens-before 4

    从内存语义上来看

    当写一个volatile变量时,JMM会把该线程对应的本地内存中的共享变量刷新到主内存

    当读一个volatile变量时,JMM会把该线程对应的本地内存置为无效,线程接下来将从主内存中读取共享变量。

    面试官:volatile的两点内存语义能保证可见性和有序性,但是能保证原子性吗?

    首先我回答是不能保证原子性,要是说能保证,也只是对单个volatile变量的读/写具有原子性,但是对于类似volatile++这样的复合操作就无能为力了,比如下面的例子:

    public class Test {
    public volatile int inc = 0;
    
    public void increase() {
    inc++;
    }
    
    public static void main(String[] args) {
    final Test test = new Test();
    for(int i=0;i<10;i++){
    new Thread(){
    public void run() {
    for(int j=0;j<1000;j++)
    test.increase();
    };
    }.start();
    }
    
    while(Thread.activeCount()>1) //保证前面的线程都执行完
    Thread.yield();
    System.out.println(test.inc);
    }

    按道理来说结果是10000,但是运行下很可能是个小于10000的值。有人可能会说volatile不是保证了可见性啊,一个线程对inc的修改,另外一个线程应该立刻看到啊!可是这里的操作inc++是个复合操作啊,包括读取inc的值,对其自增,然后再写回主存。

    假设线程A,读取了inc的值为10,这时候被阻塞了,因为没有对变量进行修改,触发不了volatile规则。

    线程B此时也读读inc的值,主存里inc的值依旧为10,做自增,然后立刻就被写回主存了,为11。

    此时又轮到线程A执行,由于工作内存里保存的是10,所以继续做自增,再写回主存,11又被写了一遍。所以虽然两个线程执行了两次increase(),结果却只加了一次。

    有人说,volatile不是会使缓存行无效的吗?但是这里线程A读取到线程B也进行操作之前,并没有修改inc值,所以线程B读取的时候,还是读的10。

    又有人说,线程B将11写回主存,不会把线程A的缓存行设为无效吗?但是线程A的读取操作已经做过了啊,只有在做读取操作时,发现自己缓存行无效,才会去读主存的值,所以这里线程A只能继续做自增了。

    综上所述,在这种复合操作的情景下,原子性的功能是维持不了了。但是volatile在上面那种设置flag值的例子里,由于对flag的读/写操作都是单步的,所以还是能保证原子性的。

    要想保证原子性,只能借助于synchronized,Lock以及并发包下的atomic的原子操作类了,即对基本数据类型的 自增(加1操作),自减(减1操作)、以及加法操作(加一个数),减法操作(减一个数)进行了封装,保证这些操作是原子性操作。

    面试官:说的还可以,那你知道volatile底层的实现机制?

    如果把加入volatile关键字的代码和未加入volatile关键字的代码都生成汇编代码,会发现加入volatile关键字的代码会多出一个lock前缀指令。

    lock前缀指令实际相当于一个内存屏障,内存屏障提供了以下功能:

    1 . 重排序时不能把后面的指令重排序到内存屏障之前的位置
    2 . 使得本CPU的Cache写入内存
    3 . 写入动作也会引起别的CPU或者别的内核无效化其Cache,相当于让新写入的值对别的线程可见。

    面试官: 你在哪里会使用到volatile,举两个例子呢?

    1. 状态量标记,就如上面对flag的标记,我重新提一下:

    int a = 0;
    volatile bool flag = false;
    
    public void write() {
    a = 2; //1
    flag = true; //2
    }
    
    public void multiply() {
    if (flag) { //3
    int ret = a * a;//4
    }
    }

    这种对变量的读写操作,标记为volatile可以保证修改对线程立刻可见。比synchronized,Lock有一定的效率提升。

    2. 单例模式的实现,典型的双重检查锁定(DCL)

    class Singleton{
    private volatile static Singleton instance = null;
    
    private Singleton() {
    
    }
    
    public static Singleton getInstance() {
    if(instance==null) {
    synchronized (Singleton.class) {
    if(instance==null)
    instance = new Singleton();
    }
    }
    return instance;
    }
    }

    这是一种懒汉的单例模式,使用时才创建对象,而且为了避免初始化操作的指令重排序,给instance加上了volatile。

    展开全文

空空如也

1 2 3 4 5 ... 20
收藏数 39,215
精华内容 15,686
关键字:

volatile