Java基础之volatile关键字

一、概述

在当前的Java内存模型下,每个线程都拥有自己的工作内存,在进行变量的操作之前,每个线程会先把要使用的变量从主内存读入到自己的工作内存,当对该变量操作完成后(如i++操作),再将该变量写会主内存,这就可能造成一个线程在主存中修改了一个变量的值,而另外一个线程还继续使用它在寄存器中的变量值的拷贝,造成数据的不一致,volatile关键字就是为了解决在并发编程的条件下数据不一致的问题。

二、三个概念

  1. 原子性
    由Java内存模型来直接保证的原子性操作包括read 、load、use、assign、store、write这六个,我们大致可以认为基本数据的访问读写操作是具备原子性的(long和double类型的读写操作也基本都实现了原子操作)。
  2. 可见性
    可见性是指当多个线程访问同一个共享变量时,一个线程改变了这个变量的值,其他线程能够立即感知到该变量的变化;
  3. 指令重排序
    一般来说,处理器为了提高程序运行效率,可能会对输入代码进行优化,它不保证程序中各个语句的执行先后顺序同代码中的顺序一致,但是它会保证程序最终执行结果和代码顺序执行的结果是一致的。

三、特点

  1. volatile关键字只能用来修饰变量。
  2. volatile变量是一种比synchronized关键字较轻量级的同步机制,也可以说是Java虚拟机提供的最轻量级的同步机制,在访问volatile变量时不会执行加锁操作,也不会造成线程的阻塞,被volatile修饰的成员变量,在各个线程的私有工作内存中不存在它的私有拷贝,各个线程在访问该变量前必须从主存(共享内存)中读取该变量的值。
  3. Java内存模型是通过将在工作内存中的变量修改后的值同步到主内存(共享内存),即原子操作(assgin-store-write)必须依次执行,在读取变量前从主内存(共享内存)刷新最新值到工作内存中来实现可见性的。
  4. volatile关键字保证了被它修饰的变量值修改后立即同步到主内存,每次使用该变量前都从主内存中刷新,即被volatile修饰的变量对所有的线程是可见的,对volatile变量的所有的写操作都能立即反映到其他线程中。
  5. 被volatile关键字修饰的变量不允许进行指令的重排序。
  6. volatile关键字只能保证共享变量的可见性,只能保证不同线程每次访问该共享变量时读取的是该变量的最新值,但不能保证对变量的操作的原子性
  7. volatile关键字无法保证操作的原子性,通常来说,使用volatile关键字必须具备以下2个条件:
    ①对变量的写操作不依赖当前值,或者能够确保只有单一的线程修改变量的值。
    ②该变量没有包含在具有其他变量的不变式中,或者说变量不需要与其它的状态变量共同参与不变约束。
    以上条件说明,n++,n--这些非原子操作不能保证volatile关键字修饰的变量在并发条件下值的正确性,而只有n=m+1,n=5,这些原子操作才能保证该变量在并发环境下值的正确性。
    来看一个例子:
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);

    }
}

变量inc声明为volatile int类型,保证了所有线程对变量inc的可见性,按照我们的目的,最后的输出结果应该为10*1000=10000,然而最后的结果均小于10000,且每次运行的结果不一,难道volatile修饰的变量的可见性特征失效了?不,volatile变量只能保证共享变量对所有线程的可见性,从Java内存模型的角度理解:被volatile关键字修饰的变量只能保证assgin->store->write操作和read->load->use操作的原子性,但inc++操作包括的原子操作有:read->load->use->assgin->store->write操作,所以自加操作并非一个原子操,线程A在读取到inc的最新值之后,在assgin操作之前可能切换到线程B,线程B此时执行的操作可能为read->load->use->assgin->store->write操作,完成了inc的自加操作,此时线程A由于已经读取到inc的值,所以不再从主存中刷新inc的值,但此时线程A的工作内存中保存的inc的值已经过期,线程A对过期的inc值进行自加操作后写会了主内存,从而造成数据的错误。

注:以上是属于个人理解,可能存在不严谨之处,也可以从JVM反编译字节码的角度来解释该原因,可参见《深入理解Java虚拟机》第十二章:Java内存模型与线程;

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 211,948评论 6 492
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,371评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,490评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,521评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,627评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,842评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,997评论 3 408
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,741评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,203评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,534评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,673评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,339评论 4 330
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,955评论 3 313
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,770评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,000评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,394评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,562评论 2 349

推荐阅读更多精彩内容