volatile在i++情况下失效,volatile不是原子的

概述

如果你对volatile不陌生的话,应该会知道volatile能够保证共享变量对线程的可见性。
那为什么volatile无法保证 i++ 操作的线程可见性呢?

分析

假设i的初始值为0,现有两个线程,分别为线程1和线程2进行 i++ 操作,我们来分析一下为什么会出现错误。
首先,i++并不是原子操作,我们可以将这个操作拆分为3个步骤。
1、线程从主内存把遍历加载到缓存。
2、线程执行i++操作。
3、线程将i的新值刷新到主内存。

那么进行如下过程,则会发生线程安全问题。
1、线程1将变量加载到缓存。但是还没有执行 i++ 操作。
2、线程2将变量加载到缓存,然后执行i++操作。
3、由于线程2缓存变量已经发生了变化,使得线程1的缓存行无效。
4、按我们以前的理解,由于线程1缓存行无效,那线程1应该主动去主内存load最新的值。而实际上并不是这样的,volatile的作用并不是在变量改变的时候,让其他线程重新加载主内存的变量值,而是置其他线程缓存内的变量值无效。也就是说,假如线程1的i值已经被加载到了寄存器,参与i++运算,那么此时即便线程1的i值被置为无效,那线程1的计算结果也会把线程1从主内存刷新到的缓存值覆盖,导致数据错误。

解决方案

那么为了解决volatile++这类复合操作的原子性,有什么方案呢?其实方案也比较多的,这里提供两种典型的:
1、使用synchronized关键字
2、使用AtomicInteger/AtomicLong原子类型

synchronized关键字

synchronized是比较原始的同步手段。它本质上是一个独占的,可重入的锁。当一个线程尝试获取它的时候,可能会被阻塞住,所以高并发的场景下性能存在一些问题。

在某些场景下,使用synchronized关键字和volatile是等价的:
1、写入变量值时候不依赖变量的当前值,或者能够保证只有一个线程修改变量值。
2、写入的变量值不依赖其他变量的参与。
3、读取变量值时候不能因为其他原因进行加锁。
加锁可以同时保证可见性和原子性,而volatile只保证变量值的可见性。

AtomicInteger/AtomicLong

这类原子类型比锁更加轻巧,比如AtomicInteger/AtomicLong分别就代表了整型变量和长整型变量。
在它们的实现中,实际上分别使用的volatile int/volatile long保存了真正的值。因此,也是通过volatile来保证对于单个变量的读写原子性的。
在此基础之上,它们提供了原子性的自增自减操作。比如incrementAndGet方法,这类方法相对于synchronized的好处是:它们不会导致线程的挂起和重新调度,因为在其内部使用的是CAS非阻塞算法。

CAS

所谓的CAS全程为CompareAndSet。直译过来就是比较并设置。这个操作需要接受三个参数:
1、内存位置
2、旧的预期值
3、新值
这个操作的做法就是看指定内存位置的值符不符合旧的预期值,如果符合的话就将它替换成新值。它对应的是处理器提供的一个原子性指令 - CMPXCHG。
比如AtomicLong的自增操作:

public final long incrementAndGet() {
    for (;;) {
        long current = get(); // Step 1
        long next = current + 1; // Step 2
        if (compareAndSet(current, next)) // Step 3
            return next;
    }
}

public final boolean compareAndSet(long expect, long update) {
    return unsafe.compareAndSwapLong(this, valueOffset, expect, update);
}

我们考虑两个线程T1和T2,同时执行到了上述Step 1处,都拿到了current值为1。然后通过Step 2之后,current在两个线程中都被设置为2。

紧接着,来到Step 3。假设线程T1先执行,此时符合CompareAndSet的设置规则,因此内存位置对应的值被设置成2,线程T1设置成功。当线程T2执行的时候,由于它预期current为1,但是实际上已经变成了2,所以CompareAndSet执行不成功,进入到下一轮的for循环中,此时拿到最新的current值为2,如果没有其它线程感染的话,再次执行CompareAndSet的时候就能够通过,current值被更新为3。
所以不难发现,CAS的工作主要依赖于两点:
1、无限循环,需要消耗部分CPU性能
2、CPU原子指令CompareAndSet
虽然它需要耗费一定的CPU Cycle,但是相比锁而言还是有其优势,比如它能够避免线程阻塞引起的上下文切换和调度。这两类操作的量级明显是不一样的,CAS更轻量一些。

总结

我们说对于volatile变量的读/写操作是原子性的。因为从内存屏障的角度来看,对volatile变量的单纯读写操作确实没有任何疑问。
由于其中掺杂了一个自增的CPU内部操作,就造成这个复合操作不再保有原子性。
然后,讨论了如何保证volatile++这类操作的原子性,比如使用synchronized或者AtomicInteger/AtomicLong原子类。

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

推荐阅读更多精彩内容