• <sup id="mk476"></sup>
    <dl id="mk476"></dl>
  • <progress id="mk476"><tr id="mk476"></tr></progress>
    <div id="mk476"><tr id="mk476"></tr></div>
    <sup id="mk476"><ins id="mk476"></ins></sup>
  • <progress id="mk476"></progress>
    <div id="mk476"></div>
    <div id="mk476"><tr id="mk476"></tr></div>
  • <div id="mk476"></div>
    <dl id="mk476"><s id="mk476"></s></dl><dl id="mk476"></dl><div id="mk476"></div>
  • <div id="mk476"></div>
    <dl id="mk476"><ins id="mk476"></ins></dl>

    并发的核心:CAS 是什么?Java8是如何优化 CAS 的?

    大家可能都听说说 Java 中的并发包,如果想要读懂 Java 中的并发包,其核心就是要先读懂 CAS 机制,因为 CAS 可以说是并发包的底层实现原理。

    今天就带大家读懂 CAS 是如何保证操作的原子性的,以及 Java8 对 CAS 进行了哪些优化。

    synchronized:大材小用

    我们先来看几行代码:

    public class CASTest {
        static int i = 0;
    
        public static void increment() {
            i++;
        }
    }

    假如有100个线程同时调用 increment() 方法对 i 进行自增操作,i 的结果会是 100 吗?

    学会多线程的同学应该都知道,这个方法是线程不安全的,由于 i++ 不是一个原子操作,所以是很难得到 100 的。

    这里稍微解释下为啥会得不到 100(知道的可直接跳过), i++ 这个操作,计算机需要分成三步来执行。
    1、读取 i 的值。
    2、把 i 加 1.
    3、把 最终 i 的结果写入内存之中。所以,假如线程 A 读取了 i 的值为 i = 0,这个时候线程 B 也读取了 i 的值 i = 0。接着 A把 i 加 1,然后写入内存,此时 i = 1。紧接着,B也把 i 加 1,此时线程B中的 i = 1,然后线程 B 把 i 写入内存,此时内存中的 i = 1。也就是说,线程 A, B 都对 i 进行了自增,但最终的结果却是 1,不是 2.

    那该怎么办呢?解决的策略一般都是给这个方法加个锁,如下

    public class CASTest {
        static int i = 0;
    
        public synchronized static void increment() {
            i++;
        }
    }

    加了 synchronized 之后,就最多只能有一个线程能够进入这个 increment() 方法了。这样,就不会出现线程不安全了。不懂 synchronized 的可以看我这篇文章:彻底搞懂synchronized(从偏向锁到重量级锁)

    然而,一个简简单单的自增操作,就加了 synchronized 进行同步,好像有点大材小用的感觉,加了 synchronized 关键词之后,当有很多线程去竞争 increment 这个方法的时候,拿不到锁的方法是会被阻塞在方法外面的,最后再来唤醒他们,而阻塞/唤醒这些操作,是非常消耗时间的。

    这里可能有人会说,synchronized 到了JDK1.6之后不是做了很多优化吗?是的,确?#24213;?#20102;很多优化,增加了偏向锁、轻量级锁等, 但是,就算增加了这些,当很多线程来竞争的时候,开销依然很多,不信你看我另外一篇文章的介绍:彻底搞懂synchronized(从偏向锁到重量级锁)

    CAS :这?#20013;?#20107;交给我

    那有没有其他方法来代替 synchronized 对方法的加锁,并且保证 increment() 方法是线程安全呢?

    大家看一下,如果我采用下面这种方式,能否保证 increment 是线程安全的呢?步骤如下:

    1、线程从内存中读取 i 的值,假如此时 i 的值为 0,我们把这个值称为 k 吧,即此时 k = 0。

    2、令 j = k + 1。

    3、用 k 的值与内存中i的值相比,如果相等,这意味着没有其他线程修改过 i 的值,我们就把 j(此时为1) 的值写入内存;如果不相等(意味着i的值被其他线程修改过),我们就不把j的值写入内存,而是重新跳回步骤 1,继续这三个操作。

    翻译成代码的话就是这样:

    public static void increment() {
        do{
            int k = i;
            int j = k + 1;
        }while (compareAndSet(i, k, j))
    }

    如果你去模拟一下,就会发现,这样写是线程安全的。

    这里可能有人会说,第三步的 compareAndSet 这个操作不仅要读取内存,还干了比较、写入内存等操作,,,这一步本身就是线程不安全的啊?

    如果你能想到这个,说明你是真的有去思考、模拟这个过程,不过我想要告诉你的是,这个 compareAndSet 操作,他其实只对应操作系统的一条硬件操作指令,尽管看似有很多操作在里面,但操作系统能够保证他是原子执行的。

    对于一条英文单词很长的指令,我们都?#19981;?#29992;它的简?#35780;?#31216;呼他,所以,我们就把 compareAndSet 称为 CAS 吧。

    所以,采用 CAS 这种机制的写法也是线程安全的,通过这种方式,可以说是不存在锁的竞争,也不存在阻塞等事情的发生,可以让程序执行的更好。

    在 Java 中,也是提供了这种 CAS 的原子类,例如:

    1. AtomicBoolean
    2. AtomicInteger
    3. AtomicLong
    4. AtomicReference

    具体如何使用呢?我就以上面那个例子进行改版吧,代码如下:

    public class CASTest {
        static AtomicInteger i = new AtomicInteger(0);
    
        public static void increment() {
            // 自增 1并返回之后的结果
            i.incrementAndGet();
        }
    }

    CAS?#26680;?#20599;偷更改了我的值

    虽然这种 CAS 的机制能够保证increment() 方法,但依然有一些问题,例如,当线程A即将要执行第三步的时候,线程 B 把 i 的?#23548;?,之后又马上把 i 的?#23548;?1,然后,线程 A 执行第三步,这个时候线程 A 是认为并没有人修改过 i 的值,因为 i 的值并没有发生改变。而这,就是我们平常说的ABA问题

    对于基本类型的值来说,这种把数字改变了在改回原来的值是没有太大影响的,但如果是对于引用类型的话,就会产生很大的影响了。

    来个版本控制吧

    为了解决这个 ABA 的问题,我们可以引入版本控制,例如,?#30475;?#26377;线程修改了引用的值,就会进行版本的更新,虽然两个线程持有相同的引用,但他们的版本不同,这样,我们就可以预防 ABA 问题了。Java 中提供了 AtomicStampedReference 这个类,就可以进行版本控制了。

    Java8 对 CAS 的优化。

    由于采用这种 CAS 机制是没有对方法进行加锁的,所以,所有的线程都可以进入 increment() 这个方法,假如进入这个方法的线程太多,就会出现一个问题?#22909;看?#26377;线程要执行第三个步骤的时候,i 的?#36947;?#26159;被修改了,所以线程又到回到第一步继续重头再来。

    而这就会导致一个问题:由于线程太密集了,太多人想要修改 i 的值了,进而大部分人都会修改不成功,白白着在那里循环消耗资源。

    为了解决这个问题,Java8 引入了一个 cell[] 数组,它的工作机制是这样的:假如有 5 个线程要对 i 进行自增操作,由于 5 个线程的话,不是很多,起冲突的几?#24335;?#23567;,那就让他们按照以往正常的那样,采用 CAS 来自增吧。

    但是,如果有 100 个线程要对 i 进行自增操作的话,这个时候,冲突就会大大增加,系统就会把这些线程分配到不同的 cell 数组元素去,假如 cell[10] 有 10 个元素吧,?#20197;?#32032;的初始化值为 0,那么系统就会把 100 个线程分成 10 组,每一组对 cell 数组其中的一个元素做自增操作,这样到最后,cell 数组 10 个元素的值都为 10,系统在把这 10 个元素的值进行汇总,进而得到 100,二这,就等价于 100 个线程对 i 进行了 100 次自增操作。

    当然,我这里只是举个例子来说明 Java8 对 CAS 优化的大致原理,具体的大家?#34892;?#36259;可以去看源码,或者去搜索对应的文章哦。

    总结

    理解 CAS 的原理还是非常重要的,它是 AQS 的基石,而 AQS 又是并发框架的基石,接下来有时间的话,还会写一篇 AQS 的文章。

    最后推广下我的公众号:苦逼的码农戳我即可关注,文章都会首发于我的公众号,期待各路英雄的关注交流。

    posted @ 2019-04-10 10:04 帅地 阅读(...) 评论(...) 编辑 收藏
    江苏11选5软件 十三水12345算顺子吗 河北快三走势图遗漏数据 一码规律 重庆幸运农场能稳赚吗 竞彩计算器胜平负 山东11选5前3 香港特码刮刮卡 体彩福建31选7六等奖 北京快3路末班车几点 河南泳坛夺金怎么玩 辽宁快乐12怎么看中奖 福彩中奖故事 9377国内网页游戏娱乐平台 福利彩票走势图七乐彩 吉林十一选五最牛走势