枯燥的J.U.C – AbstractQueuedSynchronizer(一)

时间:2021-7-4 作者:qvyue

俗话说得好,编程不识Doug Lea,写尽Java也枉然。本章将开启J.U.C源码探索,让我们通过一个ReentrantLock类,来开启AQS的大门。

枯燥的J.U.C - AbstractQueuedSynchronizer(一)
image.png

~~~~~~~~~~~~~ 祖师爷庇护,并发从此无难题。~~~~~~~~~~~~

ReentrantLock简介

ReentrantLock 是一种基于AQS框架的应用实现,是JDK中的一种线程并发访问的同步手段,它的功能类似于 synchronized 是一种互斥锁,可以保证线程安全。而且它具有比synchronized更多的特性,比如它支持手动加锁与解锁,支持加锁的公平性。

废话不多说,直接从构造开始撸:

ReentrantLock reentrantLock = new ReentrantLock(true); // true为公平锁 默认false

构造方法为以下两个:

public ReentrantLock() {
    sync = new NonfairSync();
}
public ReentrantLock(boolean fair) {
    sync = fair ? new FairSync() : new NonfairSync();
}

对象实例化后调用其加锁方法:

reentrantLock.lock();

内部逻辑:

public void lock() {
    sync.lock();  // 同步机制的实例(FairSync / NonfairSync)
}

其中 Sync 是 ReentrantLock 中的内部抽象类,它有两个实现类,本章以公平锁同步实例进行源码跟踪(主要区别是新的线程进入加锁逻辑时,非公平实现不会去看队列中是否有存在排队的线程,而是去直接尝试获取锁)。

枯燥的J.U.C - AbstractQueuedSynchronizer(一)
image.png

上图看到 ReentrantLock 中的同步实例其实是继承自 AbstractQueuedSynchronizer(也就是本章要学习的AQS),首先来看看AQS中的主要结构:

Node内部类
  /**
   * Wait queue node class
   */
  static final class Node {
    
    // 标记节点未共享模式
    static final Node SHARED = new Node();
    // 标记节点为独占模式
    static final Node EXCLUSIVE = null;

    // 在同步队列中等待的线程等待超时或者被中断,需要从同步队列中取消等待
    static final int CANCELLED =  1;
    // 后继节点的线程处于等待状态,而当前的节点如果释放了同步状态或者被取消,将会通知后继节点,使后继节点的线程得以运行。
    static final int SIGNAL    = -1;
    // 节点在等待队列中,节点的线程等待在Condition上,当其他线程对Condition调用了signal()方法后,该节点会从等待队列中转移到同步队列中,加入到同步状态的获取中
    static final int CONDITION = -2;
    // 表示下一次共享式同步状态获取将会被无条件地传播下去
    static final int PROPAGATE = -3;

   /**
    * 标记当前节点的信号量状态 (1,0,-1,-2,-3)5种状态
    * 使用CAS更改状态,volatile保证线程可见性,高并发场景下,
    * 即被一个线程修改后,状态会立马让其他线程可见。
    */
    volatile int waitStatus;
    
    // 前继节点
    volatile Node prev;
    // 后继节点
    volatile Node next;
    // 持有的线程
    volatile Thread thread;
    // 在等待队列(共享模式)中这个字段是一个SHARED常量,在等待队列(独占模式)中它与后继节点指向同一个节点;在条件队列中维护单向链表结构关系
    Node nextWaiter;

    // 返回节点是否处于Shared状态下
    final boolean isShared() {
        return nextWaiter == SHARED;
    }

    // 返回前继节点
    final Node predecessor() throws NullPointerException {
        Node p = prev;
        if (p == null)
            throw new NullPointerException();
        else
            return p;
    }
    
    // Shared模式下的Node构造函数
    Node() {  
    }

    // 用于同步队列(CLH)addWaiter
    Node(Thread thread, Node mode) {  
        this.nextWaiter = mode;
        this.thread = thread;
    }
    
    // 用于条件队列Condition
    Node(Thread thread, int waitStatus) {
        this.waitStatus = waitStatus;
        this.thread = thread;
    }
}

基于Node实现AQS当中的同步等待队列
也称 CLH 队列,CLH 队列是Craig、Landin、Hagersten三人发明的一种基于双向链表数据结构的队列,是FIFO先入先出线程等待队列,Java中的CLH队列是原CLH队列的一个变种,线程由原自旋机制改为阻塞机制。

枯燥的J.U.C - AbstractQueuedSynchronizer(一)
image.png

基于Node实现AQS当中的条件等待队列
Condition 是一个多线程间协调通信的工具类,使得某个,或者某些线程一起等待某个条件(Condition),只有当该条件具备时,这些等待线程才会被唤醒,从而重新争夺锁。

枯燥的J.U.C - AbstractQueuedSynchronizer(一)
image.png

AQS的阻塞队列是以双向链表的形式保存,是通过 prev 和 next 建立起关系的。而AQS中的条件队列是以单向链表的形式保存,是通过 nextWaiter 建立起关系的。也就是说AQS中的阻塞队列和条件队列并非同一个队列。

了解完两种阻塞队列的实现原理,我们继续看AQS的其它重要属性:

    // 指向同步等待队列的头节点
    private transient volatile Node head;

    // 指向同步等待队列的尾节点
    private transient volatile Node tail;

    // 同步资源状态
    private volatile int state;

AQS的基本工作模型:

枯燥的J.U.C - AbstractQueuedSynchronizer(一)
image.png

现在,我们已经对它做了初步的了解:AQS定义了一套多线程访问共享资源的同步器框架,是一个依赖状态(state)的同步器。

AQS内部维护了一个volatile语义(支持多线程下的可见性)的共享资源变量(state) 和一个FIFO线程等待队列(多线程竞争state 被阻塞时就会进入此队列)。

理论知识了解的差不多,我们继续回到加锁的逻辑上:

枯燥的J.U.C - AbstractQueuedSynchronizer(一)
image.png

点击进入公平锁的 lock() 方法,发现它的加锁逻辑其实只是调用了它父类的 acquire() 方法,我们来跟踪分析一下它的实现逻辑。

    public final void acquire(int arg) {
        /**
          * 1 .尝试获取锁失败后进入下个操作
          * 2. 加入阻塞队列并再次尝试获取锁,失败后阻塞当前线程直到被唤醒,会返回一个当前线程是否被中断过的标识
          */
        if (!tryAcquire(arg) &&
            acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
            selfInterrupt();
    }

直接进入子类重写的 tryAcquire() 方法:

        protected final boolean tryAcquire(int acquires) {
            final Thread current = Thread.currentThread();
            int c = getState(); // 获取状态
            if (c == 0) {
                /**
                 * 1. 队列当中如果没有等待的节点
                 * 2. 如果没有则可以尝试CAS获取锁
                 */
                if (!hasQueuedPredecessors() &&
                    compareAndSetState(0, acquires)) {
                    // 状态改变成功,独占模式的所有者设置为当前线程
                    setExclusiveOwnerThread(current);
                    return true;
                }
            }
            else if (current == getExclusiveOwnerThread()) {
                // 当前线程可重入,state+1操作
                int nextc = c + acquires;
                if (nextc 

从上面加锁逻辑我们证实了AQS同步器的确是依赖状态(state)的,如果获取锁失败呢?先看一下 addWaiter() 逻辑:

    private Node addWaiter(Node mode) {
        // 将当前线程构建成Node类型(独占模式)
        Node node = new Node(Thread.currentThread(), mode);
        // 尾节点不为空,说明队列已存在,直接从尾部插入
        Node pred = tail;
        if (pred != null) {
            node.prev = pred;
            if (compareAndSetTail(pred, node)) {
                pred.next = node;
                return node;
            }
        }
        // 初始化队列并从尾部插入
        enq(node);
        return node;
    }

入队完成后进入阻塞等待及不断自旋尝试获取锁阶段:

    final boolean acquireQueued(final Node node, int arg) {
        boolean failed = true;
        try {
            boolean interrupted = false; // 被中断标识
            for (;;) {
                final Node p = node.predecessor();
                // 如果当前节点的前驱节点是头节点,那么就去尝试获取锁
                if (p == head && tryAcquire(arg)) {
                    setHead(node);
                    p.next = null; // help GC
                    failed = false;
                    return interrupted;
                }
                /**
                 * 1. 判断是否应该被阻塞(pred.waitStatus == -1)
                 * 2. 阻塞当前线程 LockSupport.park(this) 并返回当前线程的中断状态
                 */
                if (shouldParkAfterFailedAcquire(p, node) &&
                    parkAndCheckInterrupt())
                    interrupted = true;
            }
        } finally {
            if (failed)
                cancelAcquire(node);
        }
    }

acquireQueued()方法总结为3个步骤:

  1. addWriter() 将当前线程加入到等待队列的尾部,并标记为独占模式;
  2. acquireQueued() 使线程在等待队列中获取资源,直到获取到资源返回,若整个等待过程被中断过,则返回true,否则返回false。
  3. 如果线程在等待过程中被中断过,则先标记上,待获取到资源后再进行自我中断 selfInterrupt(),将中断响应掉。

再来看下 acquireQueued()中的 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) {
            // 节点前移(移除已取消的前驱节点)
            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;
    }

shouldParkAfterFailedAcquire() 方法是判断一个争用锁的线程是否应该被阻塞。它首先判断一个节点的前置节点的状态是否为Node.SIGNAL,如果是,说明此节点已经将状态设置-如果锁释放,则应当通知它,所以它可以安全的阻塞了,返回true。否则只能通过不断自旋和改变前驱节点状态来确认是否应该被阻塞。

到此,线程获取锁资源的代码(独占模式)就跟完了,总结一下过程:

  1. 首先线程通过 tryAcquire() 方法尝试获取共享资源,若获取成功则直接返回,若不成功,则将该线程以独占模式添加到等待队列尾部,tryAcquire() 方法由继承AQS的自定义同步器来具体实现;
  2. 当前线程加入等待队列后,会通过 acquireQueued() 方法基于 CAS 自旋不断尝试获取资源,直至获取到资源;
  3. 若在自旋过程中,线程被中断过,acquireQueued() 方法会标记此次中断,并返回true。
  4. 若 acquireQueued() 方法获取到资源后,返回 true,则执行线程自我中断操作 selfInterrupt()。

最后,我们一起看下 ReentrantLock 的解锁过程:

    /**
     * 释放独占模式持有的锁
     */
    public final boolean release(int arg) {
        if (tryRelease(arg)) {
            Node h = head;
            if (h != null && h.waitStatus != 0)
                // 若头结点不为空且其ws值非0,则唤醒h的后继节点
                unparkSuccessor(h);
            return true;
        }
        return false;
    }

点击 tryRelease() 进入 ReentrantLock类实现的 tryRelease()方法:

枯燥的J.U.C - AbstractQueuedSynchronizer(一)
image.png

具体看下释放逻辑:

        protected final boolean tryRelease(int releases) {
            // 考虑到可重入,锁的数量减1
            int c = getState() - releases;
            if (Thread.currentThread() != getExclusiveOwnerThread())
                throw new IllegalMonitorStateException();
            boolean free = false;
            if (c == 0) {
                // 彻底释放锁资源
                free = true;
                setExclusiveOwnerThread(null);
            }
            setState(c);
            return free;
        }

锁资源释放成功后,开始唤醒后继节点,它传入的是head节点(head节点是占用锁的节点):

    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) {
            s = null;
            /**
              * 1. 从尾部向前遍历找到最前面的一个waitStatus小于0的节点(why?后续)
              * 2. 退出条件:要唤醒的节点不为空并且不是当前已经释放锁资源的 head节点
              */
            for (Node t = tail; t != null && t != node; t = t.prev)
                // 只有节点处于ke才能被唤醒
                if (t.waitStatus 

当阻塞队列中第一个等待节点被唤醒后,它就会继续在 acquireQueued()方法中尝试获取锁资源,之前分析过的逻辑截图如下,由于是公平锁实现缘故,它将会在此拿到锁资源:

枯燥的J.U.C - AbstractQueuedSynchronizer(一)
image.png

总结

本章基于 ReentrantLock公平锁的独占锁实现,我们初步分析了AQS(同步队列,后续还会对条件队列进行分析)的实现过程。在获得同步锁时,同步器会维护一个同步队列,获取锁资源(状态)失败的线程都会被加入到队列中并在队列中进行自旋(阻塞);移出队列(或停止自旋)的条件是前驱节点为头节点且成功获取了同步状态。在释放同步状态时,同步器调用 tryRelease()方法释放同步状态,然后唤醒头节点的后继节点。

补充内容一:AQS对中断的支持

ReentrantLock 类的 lockInterruptibly()方法可以来响应线程的中断信号(线程如果在阻塞过程中被中断,会抛出InterruptedException异常)。下面我们看下关键实现:

    private void doAcquireInterruptibly(int arg)
        throws InterruptedException {
        final Node node = addWaiter(Node.EXCLUSIVE);
        boolean failed = true;
        try {
            for (;;) {
                final Node p = node.predecessor();
                if (p == head && tryAcquire(arg)) {
                    setHead(node);
                    p.next = null; // help GC
                    failed = false;
                    return;
                }
                if (shouldParkAfterFailedAcquire(p, node) &&
                    parkAndCheckInterrupt())
                    // 若被中断,会立即向上抛出中断异常
                    throw new InterruptedException();
            }
        } finally {
            if (failed)
                cancelAcquire(node);
        }
    }

与我们上面讲到的 acquireQueued()方法的区别:
当调用线程获取锁失败,进入阻塞后,如果中途被中断,acquireQueued()只是用一个标识记录线程被中断过,而 doAcquireInterruptibly()则是直接抛出异常。

补充内容二:AQS对限时等待的支持

ReentrantLock 类还有一个 tryLock()方法,用于在指定的时间内尝试获取锁,无论是否获取成功,只要超时,就返回结果。下面直接看重点方法:

    public final boolean tryAcquireNanos(int arg, long nanosTimeout)
            throws InterruptedException {
        // 支持响应中断
        if (Thread.interrupted())
            throw new InterruptedException();
        /**
          * 1. 尝试获取独占锁
          * 2. 指定超时时间的入队等待逻辑
          */
        return tryAcquire(arg) ||
            doAcquireNanos(arg, nanosTimeout);
    }

跟入 doAcquireNanos()方法,大体逻辑一致,不同之处见注释:

    private boolean doAcquireNanos(int arg, long nanosTimeout)
            throws InterruptedException {
        if (nanosTimeout  spinForTimeoutThreshold)
                    // 阻塞指定时长,超时则线程自动被唤醒
                    LockSupport.parkNanos(this, nanosTimeout);
                if (Thread.interrupted())
                    throw new InterruptedException();
            }
        } finally {
            if (failed)
                cancelAcquire(node);
        }
    }

另外还要注意,当上面两种方式获取锁失败后,他们都会走 cancelAcquire() 来终结掉当前正在尝试获取锁的节点。

声明:本文内容由互联网用户自发贡献自行上传,本网站不拥有所有权,未作人工编辑处理,也不承担相关法律责任。如果您发现有涉嫌版权的内容,欢迎发送邮件至:qvyue@qq.com 进行举报,并提供相关证据,工作人员会在5个工作日内联系你,一经查实,本站将立刻删除涉嫌侵权内容。