草庐IT

AQS探究

ChinTsao 2023-03-28 原文

总所周知,java concurrent包的工具类是构建在AbstractQueuedSynchronizer类上的基础上的,而这个类是Doug Lea大神基于CHL队列实现的同步器。这个强大的同步器是怎样实现的呢?我们来一探究竟。

因为AQS的代码比较难以理解,我们从concurrent包下的并发工具类着手开始研究。从最简单的CountDownLatch开始,首先看它的源码


   public class CountDownLatch {
    /**
     * Synchronization control For CountDownLatch.
     * Uses AQS state to represent count.
     */
    private static final class Sync extends AbstractQueuedSynchronizer {
        private static final long serialVersionUID = 4982264981922014374L;

        Sync(int count) {
            setState(count);
        }

        int getCount() {
            return getState();
        }

        protected int tryAcquireShared(int acquires) {
            return (getState() == 0) ? 1 : -1;
        }

        protected boolean tryReleaseShared(int releases) {
            // Decrement count; signal when transition to zero
            for (;;) {
                int c = getState();
                if (c == 0)
                    return false;
                int nextc = c-1;
                if (compareAndSetState(c, nextc))
                    return nextc == 0;
            }
        }
    }

CountDownlatch类定义了一个Sync类继承自AQS,实现的了AQS的tryAcquireShared和tryReleaseShared方法,share顾名思义是共享锁。首先从await方法入手:


    public void await() throws InterruptedException {
        sync.acquireSharedInterruptibly(1);
    }

await方法调用的AQS的acquireSharedInterruptibly


    public final void acquireSharedInterruptibly(int arg)
            throws InterruptedException {
        if (Thread.interrupted())
            throw new InterruptedException();
        if (tryAcquireShared(arg) < 0)
            doAcquireSharedInterruptibly(arg);
    }

从这个方法看,await方法是可中断的,如果当前线程被中断,则直接向上抛InterruptedException。如果正常执行,则会调用tryAcquireShared方法,这个是在之类中实现的。现在回到CountDownLatch,看tryAcquireShared的实现:


   protected int tryAcquireShared(int acquires) {
            return (getState() == 0) ? 1 : -1;
        }

很简单,如果state为0则返回1,否则,返回-1。state是构造函数里传进来的。我们都知道使用CountDownlatch时传进来的数字表示并发执行的线程数,由此联想state就是持有锁的线程数。从acquireSharedInterruptibly方法可以看到,当前state!=0,即并发任务线程还没执行完时,会进入doAcquireSharedInterruptibly:


private void doAcquireSharedInterruptibly(int arg)
        throws InterruptedException {
        final Node node = addWaiter(Node.SHARED);
        boolean failed = true;
        try {
            for (;;) {
                final Node p = node.predecessor();
                if (p == head) {
                    int r = tryAcquireShared(arg);
                    if (r >= 0) {
                        setHeadAndPropagate(node, r);
                        p.next = null; // help GC
                        failed = false;
                        return;
                    }
                }
                if (shouldParkAfterFailedAcquire(p, node) &&
                    parkAndCheckInterrupt())
                    throw new InterruptedException();
            }
        } finally {
            if (failed)
                cancelAcquire(node);
        }
    }

首先看addWaiter方法


 private Node addWaiter(Node mode) {
        Node node = new Node(Thread.currentThread(), mode);
        // Try the fast path of enq; backup to full enq on failure
        Node pred = tail;
        if (pred != null) {
            node.prev = pred;
            if (compareAndSetTail(pred, node)) {
                pred.next = node;
                return node;
            }
        }
        enq(node);
        return node;
    }

也就是说在pred为null的时候会初始化队列


    private Node enq(final Node node) {
        for (;;) {
            Node t = tail;
            if (t == null) { // Must initialize
                if (compareAndSetHead(new Node()))
                    tail = head;
            } else {
                node.prev = t;
                if (compareAndSetTail(t, node)) {
                    t.next = node;
                    return t;
                }
            }
        }
    }

从上面代码看初始化之后的队列是这样的:

线程队列.jpg

head只是指向一个空节点,这一点对于理解后面的代码很重要,再回到doAcquireSharedInterruptibly,p的前继节点就是head,所以会进入下面的if分支(至于为什么有这个if判断后面再详解),对于CountDownLatch,在并发任务还没完成的时候,tryAcquireShared返回值为-1,所以就不会往下走。直接进入shouldParkAfterFailedAcquire


private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
        int ws = pred.waitStatus;
        if (ws == Node.SIGNAL)
            /*
             * This node has already set status asking a release
             * to signal it, so it can safely park.
             */
            return true;
        if (ws > 0) {
            /*
             * Predecessor was cancelled. Skip over predecessors and
             * indicate retry.
             */
            do {
                node.prev = pred = pred.prev;
            } while (pred.waitStatus > 0);
            pred.next = node;
        } else {
            /*
             * waitStatus must be 0 or PROPAGATE.  Indicate that we
             * need a signal, but don't park yet.  Caller will need to
             * retry to make sure it cannot acquire before parking.
             */
            compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
        }
        return false;
    }

pred就是head,初始化之后waitStatus=0,进入else分支,故head的waitStatus被更新为SIGNAL,再回到doAcquireSharedInterruptibly,这个时候如果线程没有被中断,那么会接着循环,再次进入shouldParkAfterFailedAcquire,这个是进入第一个if分支,返回true,那么就是进入parkAndCheckInterrupt,将当前线程阻塞住,这就是CountDownlatch调用await后阻塞住的原因。

从上面的分析可以知道,对于CountDownlatch,在并发任务还没结束的时候,如果另外一个线程B再调用await方法,那么当前线程会放到等待队列的最后面。第一个节点park住的时候,它的waitStatus还是0,所以这次,shouldParkAfterFailedAcquire会把第一个节点的waitStatus设置为SIGNAL,同时下次循环会park住线程B

AQS获取锁的过程已经了解清楚了,下面来看看AQS释放锁的过程。还是从CountDownLatch的countdown()方法入手。countdown()是直接调用AQS的releaseShared


    public final boolean releaseShared(int arg) {
        if (tryReleaseShared(arg)) {
            doReleaseShared();
            return true;
        }
        return false;
    }

从代码看,tryReleaseShared是在子类中实现的:


        protected boolean tryReleaseShared(int releases) {
            // Decrement count; signal when transition to zero
            for (;;) {
                int c = getState();
                if (c == 0)
                    return false;
                int nextc = c-1;
                if (compareAndSetState(c, nextc))
                    return nextc == 0;
            }
        }

从tryReleaseShared方法代码来看,只有等所有并发任务执行完,tryReleaseShared才会返回true,才会执行doReleaseShared


private void doReleaseShared() {
        /*
         * Ensure that a release propagates, even if there are other
         * in-progress acquires/releases.  This proceeds in the usual
         * way of trying to unparkSuccessor of head if it needs
         * signal. But if it does not, status is set to PROPAGATE to
         * ensure that upon release, propagation continues.
         * Additionally, we must loop in case a new node is added
         * while we are doing this. Also, unlike other uses of
         * unparkSuccessor, we need to know if CAS to reset status
         * fails, if so rechecking.
         */
        for (;;) {
            Node h = head;
            if (h != null && h != tail) {
                int ws = h.waitStatus;
                if (ws == Node.SIGNAL) {
                    if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
                        continue;            // loop to recheck cases
                    unparkSuccessor(h);
                }
                else if (ws == 0 &&
                         !compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
                    continue;                // loop on failed CAS
            }
            if (h == head)                   // loop if head changed
                break;
        }
    }

如果head节点的waitStatus为SIGNAL,则先把head节点的status设置为0,然后进入unparkSuccessor


private void unparkSuccessor(Node node) {
        /*
         * If status is negative (i.e., possibly needing signal) try
         * to clear in anticipation of signalling.  It is OK if this
         * fails or if status is changed by waiting thread.
         */
        int ws = node.waitStatus;
        if (ws < 0)
            compareAndSetWaitStatus(node, ws, 0);

        /*
         * Thread to unpark is held in successor, which is normally
         * just the next node.  But if cancelled or apparently null,
         * traverse backwards from tail to find the actual
         * non-cancelled successor.
         */
        Node s = node.next;
        if (s == null || s.waitStatus > 0) {
            s = null;
            for (Node t = tail; t != null && t != node; t = t.prev)
                if (t.waitStatus <= 0)
                    s = t;
        }
        if (s != null)
            LockSupport.unpark(s.thread);
    }

在通常情况下,s!=null并且s.waitStatus为SIGNAL,所以head节点的后继节点会被唤醒。就是说每次调用releaseShared只会唤醒等待队列中head节点之后的线程。

分析到这里,试想这个使用CountDownLatch场景,线程A和线程B,都调用await方法等待线程B、线程C完成任务。那么在线程B、线>程C完成任务的时候,主线程调用releaseShared进入doReleaseShared唤醒head节点之后的节点线程。因为原来的线程是在doAcquireSharedInterruptibly里的for循环最后park住,现在仍然回到该处,继续下次循环。这个时候会进入上面提到的if分支,进入setHeadAndPropagate。


    private void setHeadAndPropagate(Node node, long propagate) {
        Node h = head; // Record old head for check below
        setHead(node);
        /*
         * Try to signal next queued node if:
         *   Propagation was indicated by caller,
         *     or was recorded (as h.waitStatus) by a previous operation
         *     (note: this uses sign-check of waitStatus because
         *      PROPAGATE status may transition to SIGNAL.)
         * and
         *   The next node is waiting in shared mode,
         *     or we don't know, because it appears null
         *
         * The conservatism in both of these checks may cause
         * unnecessary wake-ups, but only when there are multiple
         * racing acquires/releases, so most need signals now or soon
         * anyway.
         */
        if (propagate > 0 || h == null || h.waitStatus < 0) {
            Node s = node.next;
            if (s == null || s.isShared())
                doReleaseShared();
        }
    }

从代码来看,setHeadAndPropagate就是把当前当前head节点remove掉,设置当前线程节点为head节点(也就是第二个节点)。同时在共享锁的模式下,会调用doReleaseShared,唤醒当前节点的后继节点,这就是propagate的概念。同理后续节点又会再唤醒它后面的节点,直到整个队列都被唤醒。

至此,已基本了解AQS的工作原理的,为了加深印象,我们来看下面的线程队列的变化过程图。

线程thread1调用acquireSharedInterruptibly之后,线程队列如下图,同时thread1被park住


另外一个线程thead2再次调用acquireSharedInterruptibly之后,线程队列如下图,同时thread2被park住


这个时候,另一个线程触发releaseShared,线程队列如下图,同时thread1被unpark

thread1被unpark之后,会进入setHeadAndPropagate,setHead之后,线程队列如下图


thread1调用doReleaseShared唤醒thread2后,线程队列如下图


thread2 进入setHeadAndPropagate,setHead之后,线程队列如下图


有关AQS探究的更多相关文章

  1. ChatGPT探索系列之三:探究ChatGPT的训练、优化和应用方法 - 2

    文章目录前言一、ChatGPT训练原理二、采样和微调阶段三、采样和训练奖励模型阶段三、采样和训练奖励模型阶段总结前言ChatGPT发展到目前,其实网上已经有大量资料了,博主做个收口,会出一个ChatGPT探索系列的文章,帮助大家深入了解ChatGPT的。整个系列文章会按照一下目标来完成:理解ChatGPT的背景和应用领域;学习GPT模型系列的发展历程和原理;探究ChatGPT的训练、优化和应用方法;分析ChatGPT在各领域的实际案例;讨论人工智能伦理问题及ChatGPT的责任;思考ChatGPT的未来发展趋势和挑战。本次ChatGPT探索系列之一的主题是探究ChatGPT的训练、优化和应用方

  2. remix Web3 provider连接不上探究 - 2

    以太坊这东西太奇怪,remixWeb3provider连接不上探究欢迎使用Markdown编辑器连不上连上了欢迎使用Markdown编辑器首先给一张,连接成功的图注意两个地址,第一个http://…没有shttp://remix.ethereum.org/#optimize=false&runs=200&evmVersion=null&version=soljson-v0.8.7+commit.e28d00a7.js注意两个地址,第二个https://…有shttps://remix.ethereum.org/#optimize=false&runs=200&evmVersion=null&v

  3. AAX影响力实验室探究加密产业对各行业的影响 - 2

    作为领先的加密平台之一,AAX最近宣布推出AAX影响力实验室(AAXImpactLab),专注于促进加密和区块链领域的创新。AAX影响力实验室是一个关注于合作研究的团队,致力于探索和分享数字资产让世界变得更美好的新方式,希望通过强调这项技术解决的重要社会和环境问题来促进有意义的加密采用。AAX影响力实验室定期按主题发布不同的报告,系统地深入研究加密产业对各个行业带来的影响。目前,AAX影响力实验室已经发布了三份重磅的主题报告,分别是:《NFT在社群中的影响力》、《NFT对环境、社会责任和公司治理(ESG)影响力》、《NFT与音乐—解放音乐人身上的枷锁》。NFT在社群中的影响力随着越来越多人加入

  4. Rocket MQ报错No route info of this topic的问题探究 - 2

    背景系统订单创建成功之后需要发送订单创建成功的消息,但是今天突然遇到了如下的报错org.apache.rocketmq.client.exception.MQClientException:Norouteinfoofthistopic,TopicTestSeehttp://rocketmq.apache.org/docs/faq/forfurtherdetails.atorg.apache.rocketmq.client.impl.producer.DefaultMQProducerImpl.sendDefaultImpl(DefaultMQProducerImpl.java:610)ator

  5. java - 关于java中重载和类型提升的理论探究 - 2

    如果有add(int,long)和add(long,int)两种方法,则调用add(10,10)将被视为歧义。但是如果我们有这样的例子怎么办,为什么它仍然被认为是歧义?staticvoidadd(shortnum1,shortnum2){System.out.println("add(short,short)");}staticvoidadd(bytenum1,longnum2){System.out.println("add(byte,long)");}publicstaticvoidmain(String[]args){bytenum1=10;bytenum2=10;add(num

  6. 探究阿里云物联网开发板1-Haas 100 - 2

    探究阿里云物联网开发板1-Haas前言环境准备VSCodeVSCode下载安装配置VSCode下载安装配置开发板烧录代码HaasStudio新建项目编译烧录查看日志总结前言已经很久没写博客了,昨天接触了下阿里云的物联网开发板haas100。之前玩过树莓派,但是说实话我之前玩的树莓派和嵌入式还是有区别,我是直接远程连接上树莓派,在树莓派的操作系统上进行操作,而昨天接触的Haas100更多的是嵌入式编程即在我的Win10系统上完成代码编写再烧录进开发板中。虽然阿里云上有官方文档,但我还是遇到了一些问题,所以想记录下,记录的内容比较浅,大佬勿喷。另附阿里云上的官方文档Haas100快速开始需要说明的

  7. 关于应用RestHighLevelClient操作ElasticSearch出现“远程主机强迫关闭一个现有连接”的问题探究 - 2

    问题背景 各行各业都在大谈“整合”,每一个“整合”概念背后又是海量数据的支撑。ElasticSearch、Solr等搜索引擎更是在这个风口大显神通。最近在应用ElasticSearch改造会员系统时遇到了这样一个问题:某一用户在长时间无动作后,再向ES发送请求,先是长时间Loading,而后出现报错“远程主机强迫关闭了一个现有连接”。而在报错后再次发送请求一切又正常了。 从现象上推测,很可能是由于连接超时导致的错误(其实并不完全是)。大胆猜想,小心求证(此部分并非正解,着急的同学可跳过)这里梳理下求证过程:我在springboot项目中采用RestHighLevelClient对Elastic

  8. Android Studio targetApi=33 android 13 setAppCacheEnabled/setAppCachePath/setAppCacheMaxSize 报红问题探究 - 2

    报红如下可以看到即使加了Api版本判断依然是报红的编译后有如下类似错误提示Launchinglib/main.dartonsdkgphone64arm64indebugmode.../Users/dararii/Dev/flutter/.pub-cache/hosted/pub.dartlang.org/flutter_inappwebview-5.4.3+7/android/src/main/java/com/pichillilorenzo/flutter_inappwebview/in_app_webview/InAppWebView.java:280:error:cannotfindsy

  9. 学习总结-Cyberplayer视频播放器移动端手机百度打开全屏问题探究 - 2

    【最新版本的已经修复屏蔽了双击】移步https://bce.bdstatic.com/jwplayer/4.1.6.1/cyberplayer.js【问题背景】移动端h5页面使用了Cyberplayer,官网文档移步这里百度云-cyberplayerDemo,使用的老版本的js,在使用过程中发现,用手机百度扫码,安卓环境打开用到这个播放器的页面,双击全屏(咱也不知道这个双击全屏是不是安卓特有的,不过确实只有安卓有问题,前端工程师兼容移动端的艰辛。。。)播放视频会出现黑屏现象。使用全屏按钮可以正常播放。【探究过程】1、浏览器排查全屏是内部事件,双击唤起的方式内部和点按钮看起来不太一致,cyber

  10. C++ | 探究拷贝对象时的一些编译器优化 - 2

    👑作者主页:@烽起黎明🏠学习社区:烈火神盾🔗专栏链接:C++文章目录前言一、传值传参二、传引用传参三、传值返回拷贝构造和赋值重载的辨析四、传引用返回【❌】五、传匿名对象返回六、总计与提炼前言在传参和传返回值的过程中,一般编译器会做一些优化,减少对象的拷贝,这个在一些场景下还是非常有用的经过深度探索类的六大天选之子学习,我们讲到了拷贝构造一些基本概念和调用形式经过构造函数的初始化列表的学习,我们知道了原来祖师爷在构造函数里还藏着这么个东西经过explicit关键字的学习,我们清楚了可以手动去禁用构造函数的隐式转换,本文继续细谈经过类中的static成员的学习,我们认识到类中的这两个双胞胎还真是不

随机推荐