AQS(AbstractQueuedSynchronizer)解析

AbstractQueuedSynchronizer是JUC包下的一个重要的类，JUC下的关于锁相关的类(如：ReentrantLock)等大部分是以此为基础实现的。那么我们就来分析一下AQS的原理。

1：通过以前的了解，我们先明白几个有用信息。

　　1：实现基于FIFO(一个先进先出的队列)

　　2：通过一个原子变量(atomic int) state来标识锁的状态(获取和释放)

　　3：子类应该通过自定义改变原子变量的方法来代表锁的获取和释放

　　4：底层是基于unsafe包的CAS操作，我们这里不做说明。

2：既然是一个队列，那么我们看一下这个队列的节点，部分代码如下

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;
 
        static final int CONDITION = -2;
 
        static final int PROPAGATE = -3;
 
        volatile int waitStatus;
 
        volatile Node prev;
 
        volatile Node next;
 
        volatile Thread thread;
 
        Node nextWaiter;
 
        final boolean isShared() {
            return nextWaiter == SHARED;
        }
 
        final Node predecessor() throws NullPointerException {
            Node p = prev;
            if (p == null)
                throw new NullPointerException();
            else
                return p;
        }
 
        Node() {    // Used to establish initial head or SHARED marker
        }
 
        Node(Thread thread, Node mode) {     // Used by addWaiter
            this.nextWaiter = mode;
            this.thread = thread;
        }
 
        Node(Thread thread, int waitStatus) { // Used by Condition
            this.waitStatus = waitStatus;
            this.thread = thread;
        }
    }

　　这个类比较简单，我们可以看出这个队列其实就是一个保存了线程信息的双向链表。其中 SHARED和EXCLUSIVE这两个属性分别标识了共享和独占(共享锁和独占锁)。我们特殊关注一下waitStatus这个属性，他有以下几个状态

　　SIGNAL: 表明它的下一个节点的线程正在被阻塞(park)；当前节点释放锁或者被取消时，它必须唤醒(unpark)下一个节点的线程；
　　CANCELLED：该节点因为超时或者中断被取消，该状态的节点永远不会改变当前状态（会一直保持 CANCELLED 状态），同时该节点永远不会再被阻塞。
　　CONDITION：该节点目前位于一个条件队列，在其状态改变之前他不会转移到同步队列中，并且当他转移到同步队列时它的状态会被设置为默认值。
　　PROPAGATE：共享同步模式会无条件的传播给其它节点，当节点为头结点时在 doReleaseShared 方法中被设置为该状态来保证状态继续传播。
　　0:非上述4中状态，有可能是刚获取signal,此时它的值是0，也有可能是新建的head节点

　　如果上面的有些状态你看的云里雾里，不明所以的话不要紧，可以先有个大致印象。在后续的代码中看到这些状态时再结合这些解释看，就会清晰不少。

3下面是几个比较基础的方法，我们可以看下

    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;
                }
            }
        }
    }

　　这个方法就是往队列尾部添加节点，比较简单，我们不再多说。

    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;
    }

　　这个方法是对enq方法的封装,也没啥好说的。但是我们能看到先快速添加到队列尾部，失败的话再通过enq循环尝试添加。

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

　　这个方法的作用很明显了，就是唤醒当前节点的后续节点。在这之前会尝试更改锁标志状态，如果失败了也没关系，因为后置节点的线程会继续更改。但是，你有没有发现，在查找非空非取消状态的节点的时候竟然从后往前找，这感觉不太合理啊。从前往后找不是能更快的找到后置非空非取消状态的节点吗？我们记着这个问题继续看。

4：接下来我们看下独占模式下的获取锁的代码

    public final void acquire(int arg) {
        if (!tryAcquire(arg) &&
            acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
            selfInterrupt();
    }protected boolean tryAcquire(int arg) {
        throw new UnsupportedOperationException();
    }

　　acquire和release分别对应了加锁和解锁。但是方法体中tryAcquire和tryRelease方法没有具体实现，因为不同的锁对公平，非公平，重入，不可重入的要求不同，所以这部分的自由度比较高，需要自己定制。

　　我们看acquire方法：首先通过tryAcquire来获取锁，如果获取失败，则通过addWaiter将当前线程添加到队列尾部，然后通过acquireQueued来判断当前节点的线程是该阻塞呢还是不断尝试获取锁。看下面代码

    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);
        }
    }
 
    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;
    }
 
    private final boolean parkAndCheckInterrupt() {
        LockSupport.park(this);
        return Thread.interrupted();
    }

　　acquireQueued方法会判断当前节点的前置节点是不是head节点，如果是且尝试获取到了锁(说明head节点已经释放锁)，那么则设置当前节点为head节点，当先线程也不需要阻塞。如果前置阶段不为head节点或者尝试获取锁失败，那么就通过shouldParkAfterFailedAcquire方法来判断该线程是不是应该阻塞。

　　在shouldParkAfterFailedAcquire方法中我们可以看到对各种 waitStatus 状态的处理。特别注意ws>0时的处理：这段逻辑将队列中最后一个节点链接到了前一个没有CANCELLED的节点，即剔除了中间状态为CANCELLED的节点。这个确保了最后节点的前一个节点的状态为SIGNAL。这样的话下次循环该线程就可以放心park了。

5：接下来我们看下独占模式下的释放锁的代码

    public final boolean release(int arg) {
        if (tryRelease(arg)) {
            Node h = head;
            if (h != null && h.waitStatus != 0)
                unparkSuccessor(h);
            return true;
        }
        return false;
    }
 
    protected boolean tryRelease(int arg) {
        throw new UnsupportedOperationException();
    }

　　代码逻辑比较清晰：当锁释放成功后，要唤醒下一个节点的线程。同样的tryRelease需要自己实现。

　　我们看看是如何唤醒下个节点的线程的。

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

　　这个逻辑也比较简单，从后往前找到第一个状态不为CANCELLED的节点，并通过unpark唤醒它的线程。(注意这里仍然是从后向前遍历)

　　这里要注意一点：当head和s之间存在CANCELLED节点时，s.prev节点是CANCELLED节点(这点可能会在6里出问题)

6：线程被唤醒后？　

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

　　前面我们看到线程是在 acquireQueued 方法的 parkAndCheckInterrupt() 这被阻塞的。当它被唤醒后，仍在这个循环里。下次循环就能获取到锁了。

　　但是被唤醒节点的前置节点一定是head节点吗？理论上是的，但是通过5我们知道也可能不是head节点，而是一个CANCELLED节点。

　　那么被唤醒节点的前置节点是CANCELLED节点怎么处理了呢。根据逻辑，又进入了  shouldParkAfterFailedAcquire 方法，这个方法会清除两个节点间的CANCELLED节点。在经过这个方法后，就能保证在下次循环中被唤醒节点的前置节点就是head节点。

6：为什么从后向前遍历？

　　看了半天也没看出来为啥从后向前遍历。

　　我们看了 volatile Node next  属性的注释

        /**
         * Link to the successor node that the current node/thread
         * unparks upon release. Assigned during enqueuing, adjusted
         * when bypassing cancelled predecessors, and nulled out (for
         * sake of GC) when dequeued.  The enq operation does not
         * assign next field of a predecessor until after attachment,
         * so seeing a null next field does not necessarily mean that
         * node is at end of queue. However, if a next field appears
         * to be null, we can scan prev's from the tail to
         * double-check.  The next field of cancelled nodes is set to
         * point to the node itself instead of null, to make life
         * easier for isOnSyncQueue.
         */
        volatile Node next;

　　红字表出来的意思是，"enq操作在当前节点加入队列后，才将前置节点的next指向最后的节点。这说明我们从前向后遍历时，看到一个next为null的节点并不意味着他是最后一个节点。但是从后向前遍历却能避免这个问题"

　　结合代码我们再看一下

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

　　对应的8,9,10行。因为不是原子操作，有可能出现：第9行执行成功后(此时新节点已经添加到了队列尾部)，有个线程从前到后遍历各个节点，由于前置节点t.next==null,所以新追加到队列尾部的节点无法被扫描到。相反的从后向前的话，第8行就避免了这个问题。

7：总结

　　1：AQS的本质是CAS自旋 volatile 变量

　　2：阻塞的线程被有序的排列在FIFO中

　　3：线程的阻塞和唤醒用的是LockSupport.park()和LockSupport.unpark()

　　4: sleep, wait, park的区别：

　　　　sleep， 进入TIMED_WAITING状态，不出让锁;

　　　　wait, 进入TIMED_WAITING状态，出让锁，并进入对象的等待队列，必须结合sychronized使用。

　　　　park, 进入WAITING状态，对比wait不需要获得锁就可以让线程WAITING，通过unpark唤醒

关于线程阻塞和等待状态的区别见：https://blog.csdn.net/Mrxingyong/article/details/95164329