AQS深入理解 hasQueuedPredecessors源码分析 JDK8

前言

Queries whether any threads have been waiting to acquire longer than the current thread.

首先要知道hasQueuedPredecessors这个方法是为 公平锁为设计的函数，看名字就知道，这是用来判断有没有别的线程排在了当前线程的前面。

JUC框架 系列文章目录

流程

已经熟悉流程的同学可跳过。
首先看到ReentrantLock的内部类FairSync：

    public void lock() {
        sync.lock();  //此时sync成员是一个FairSync实例
    }

    static final class FairSync extends Sync {
        private static final long serialVersionUID = -3000897897090466540L;

        final void lock() {
            acquire(1);
        }

        /**
         * Fair version of tryAcquire.  Don't grant access unless
         * recursive call or no waiters or is first.
         */
        protected final boolean tryAcquire(int acquires) {
            final Thread current = Thread.currentThread();
            int c = getState();
            if (c == 0) {
                if (!hasQueuedPredecessors() &&  //调用在这里
                    compareAndSetState(0, acquires)) {
                    setExclusiveOwnerThread(current);
                    return true;
                }
            }
            else if (current == getExclusiveOwnerThread()) {
                int nextc = c + acquires;
                if (nextc < 0)
                    throw new Error("Maximum lock count exceeded");
                setState(nextc);
                return true;
            }
            return false;
        }
    }

我们调用ReentrantLock的lock方法时，最终会调用到FairSync实例的acquire方法，而acquire方法已经在AQS中有实现了：

    public final void acquire(int arg) {
        if (!tryAcquire(arg) &&  //tryAcquire是子类的实现，见上面代码
            acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
            selfInterrupt();
    }

    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;
                }
                if (shouldParkAfterFailedAcquire(p, node) &&
                    parkAndCheckInterrupt())
                    interrupted = true;
            }
        } finally {
            if (failed)
                cancelAcquire(node);
        }
    }

现在观察tryAcquire的逻辑（直接考虑当前同步器的state为0）：

• 发现如果调用hasQueuedPredecessors返回true的话，后继代码都不走了，直接就返回false了。
• 如果调用hasQueuedPredecessors返回false的话，才去尝试CAS修改同步器的状态：
  • 如果CAS修改同步器的状态 成功，通过setExclusiveOwnerThread设置 独占模式下的线程。返回true。
  • 如果CAS修改同步器的状态 失败。返回false。

可见hasQueuedPredecessors的返回值很重要，直接影响到 是否会去 尝试CAS修改同步器的state。

如果只有一个线程来调用ReentrantLock的lock方法，且该同步器state还是0，那么此时tryAcquire（看名字就知道，尝试获得锁）已经执行成功并返回true。再观察!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg)，可见后续操作也不会执行了，if分支也不会进入了。否则执行后续操作acquireQueued(addWaiter(Node.EXCLUSIVE), arg)。

addWaiter简单地说，就是把当前线程包装成一个node放在队尾，并返回这个刚建的node。acquireQueued简单的说，就是执行一个for循环，每次循环都会tryAcquire一下，如果tryAcquire成功，设置头节点后结束循环；如果tryAcquire失败，调用shouldParkAfterFailedAcquire设置上一个node的signal信号，然后调用parkAndCheckInterrupt便阻塞在里面。重点在于，这个for循环不是连续执行的，而可能 不停地 阻塞然后被唤醒 ，重复着这样的过程。

hasQueuedPredecessors分析

    public final boolean hasQueuedPredecessors() {
        // The correctness of this depends on head being initialized
        // before tail and on head.next being accurate if the current
        // thread is first in queue.
        Node t = tail; // Read fields in reverse initialization order
        Node h = head;
        Node s;
        return h != t &&
            ((s = h.next) == null || s.thread != Thread.currentThread());
    }

要分析上面return的逻辑，必须要看线程获取同步器state失败时（tryAcquire(arg)返回false），要执行的入队操作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;//这里只是执行一个快速操作，它和enq里的else分支的逻辑一样
            if (compareAndSetTail(pred, node)) {
                pred.next = node;
                return node;
            }
        }
        enq(node);//如果上面快速操作没有成功，再执行enq
        return node;
    }

    private Node enq(final Node node) {
        for (;;) {//使用for循环，保证入队成功
            Node t = tail;
            if (t == null) { // 第一次入队，没有dummy node的存在，需先创建它
                if (compareAndSetHead(new Node()))
                    tail = head;
            } else { // 至少有一个node，尝试入队
                node.prev = t;
                if (compareAndSetTail(t, node)) {
                    t.next = node;
                    return t;
                }
            }
        }
    }

首先解释下，hasQueuedPredecessors在先后读取完tail和head后，如果这二者只有一个为null（另一个不为null），那么只可能出现“head不为null，tail为null”的情况：

• 从if (compareAndSetHead(new Node()))到tail = head;的间隙可知，除非一个线程恰好在tail = head;之前读取了tali域（Node t = tail; Node t = head;），那么才可能发生 此时 head不为null，tail为null的情况。
• 否则，其他情况下。head和tail要都为null，要么都不为null。

接下来分析hasQueuedPredecessors的返回判断。首先要知道，hasQueuedPredecessors返回true代表有别的线程在CHL队列中排了当前线程之前；返回false代表当前线程处于CHL队列的第一个线程。

1. 分析h != t返回false的情况。此时hasQueuedPredecessors返回false。

   • 当h和t都为null，返回false。此时说明队列为空，还从来没有Node入过队。
   • 当h和t都指向同一个Node，也返回false。此时说明队列中只有一个dummy node，那说明没有线程在队列中。

2. 分析h != t返回true，且(s = h.next) == null返回true，直接短路后面。此时hasQueuedPredecessors返回true。

   • 既然h != t返回true，说明h和t不相等，先考虑特殊情况（上面讲到的出现“head不为null，tail为null”的情况，此时head是空node，next成员肯定为null），那么说明有一个线程正在执行enq，且它正好执行到if (compareAndSetHead(new Node()))到tail = head;的间隙。但这个线程肯定不是当前线程，所以不用判断后面短路的s.thread != Thread.currentThread()了，因为当前线程连enq都没开始执行，但另一个线程都开始执行enq了，那不就是说明当前线程排在别人后面了，别的线程马上就要入队了。
   • 既然h != t返回true，说明h和t不相等，再考虑二者都不为null。那此时队列中已经至少有一个等待中的线程了，那说明当前线程肯定排在别人后面了。

3. 分析h != t返回true，且(s = h.next) == null返回false，且s.thread != Thread.currentThread()返回true。此时hasQueuedPredecessors返回true。如果s.thread != Thread.currentThread()返回false。此时hasQueuedPredecessors返回false。

   • 现在知道head不为null，而且head.next也不为null了（(s = h.next) == null返回false）。我们也知道队列中第一个等待的线程存放在head.next里（注意，head为dummy node，不存放线程），那么如果head.next的线程不是当前线程，那即说明当前线程已经排在别人线程后面了。

为什么先读取tail，再读取head

前面说到，hasQueuedPredecessors在先后读取完tail和head后，如果这二者只有一个为null（另一个不为null），那么只可能出现“head不为null，tail为null”的情况。

现在假设当前线程正要执行这两句：

        Node t = tail; 
        Node h = head;

另一个线程则正要执行这两句（标记了1 2）：

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

现在任意排列这四条语句的顺序，但保持 各个线程的先后顺序。

可见只会出现上面三种情况。

但如果hasQueuedPredecessors先读取head后读取tail，则可能发生“head为null，tail不为null”的情况（分析类似上图），而接下来的(s = h.next) == null这里，就抛出空指针异常了。

先读取tail，再读取head的好处

当Node t = tail; Node h = head;执行完毕，只可能出现三种情况：

• h和t都为null
• h和t都不为null
• h不为null，但t为null

不可能出现：

• t不为null，但h为null

从而避免了(s = h.next) == null这里的空指针异常。

是否需要考虑 指令重排序

如果考虑指令重排序，那么可能 就变成了 先读取head再读取tail 了，那就可能不对了。但由于这两句都是volatile写操作，每个volatile写操作前面加StoreStore屏障，后面加StoreLoad内存屏障。

StoreStore 屏障：保证在 volatile 写之前，其前面的所有普通写操作，都已经刷新到主内存中。
StoreLoad 屏障：避免 volatile 写，与后面可能有的 volatile 读 / 写操作重排序。

根据StoreLoad屏障的作用，我们可以保证线程是 先读取tail后读取head。

虚假返回的true和false

虚假返回true

Note that because cancellations due to interrupts and timeouts may occur at any time, a true return does not guarantee that some other thread will acquire before the current thread.

注意，由于中断和超时导致的取消可能随时发生，因此返回true不能保证某些其他线程将在当前线程之前获取。

比如当你调用了acquireInterruptibly时，如果因为获取不到锁，会暂时阻塞在parkAndCheckInterrupt里。

    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);//②
        }
    }

• 现在，阻塞在parkAndCheckInterrupt里的线程已经被唤醒，但在此之前被设置了中断状态，所以马上抛出InterruptedException。然后再执行cancelAcquire，被唤醒的线程的所在的node才会被移除出队列。
• 但在cancelAcquire执行完之前，head.next则还是一个即将被移除的node。而此时 别的线程执行hasQueuedPredecessors肯定返回true，所以说它是虚假的true（考虑队列只有dummy node和一个即将被移除的node）。

虚假返回false

Likewise, it is possible for another thread to win a race to enqueue after this method has returned false, due to the queue being empty.

同样，由于队列为空，此方法返回false后，另一个线程也有可能赢得竞争。

这个情况比较容易想到，当队列为空时（连dummy node都没有），同时有两个线程正在执行tryAcquire，且两个线程都刚执行完了hasQueuedPredecessors。

• 此时两个线程获得的hasQueuedPredecessors的返回值肯定都是false。
• 但接下来的CAS操作compareAndSetState(0, acquires)，就不一定是谁胜出了。
• 失败了那一方，就认为 之前调用hasQueuedPredecessors返回的false，是一个虚假的false。

        protected final boolean tryAcquire(int acquires) {
            final Thread current = Thread.currentThread();
            int c = getState();
            if (c == 0) {
                if (!hasQueuedPredecessors() && //两个线程都执行到这里
                    compareAndSetState(0, acquires)) {
                    setExclusiveOwnerThread(current);
                    return true;
                }
            }
            else if (current == getExclusiveOwnerThread()) {
                int nextc = c + acquires;
                if (nextc < 0)
                    throw new Error("Maximum lock count exceeded");
                setState(nextc);
                return true;
            }
            return false;
        }

当然针对这种虚假的false，是不会有什么坏影响的，因为acquireQueued中会再次执行tryAcquire的。