JUC-AQS框架

一：什么是AQS  

   AQS(AbstractQueuedSynchronizer)是JUC中的基础框架，例如ReentrantLock,CountDownLatch等组件都是基于AQS实现同步控制。

二：AQS独占式获取和释放同步状态

 在了解AQS中线程如何获取同步状态前，需要了解Node类， AQS内部由一个双向队列实现对同步状态的管理，可以看成多生产者单消费者模型，当线程没有获取到同步状态，线程会被封装成一个Node节点，利用CAS添加至队列的尾部，当节点的前驱节点是头节点才有机会获取同步状态。

 AQS获取同步状态分为独占式和共享式获取同步状态。

     独占式：某一时刻只有一个线程能获取同步状态(ReentrantLock依靠AQS的独占式实现)。

     共享式：则可以多个线程获取同步状态(ReentrantReadWriteLock依靠AQS的共享式实现)。

   由于独占式和共享式获取同步状态的代码大体相同，本文主要分析独占式获取同步状态，弄懂独占式获取同步状态代码两者肯定都能懂。

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;

/** 等待状态 */
volatile int waitStatus;

/** 前驱节点，当节点添加到同步队列时被设置（尾部添加） */
volatile Node prev;

/** 后继节点 */
volatile Node next;

/** 等待队列中的后续节点。如果当前节点是共享的，那么字段将是一个 SHARED 常量，也就是说节点类型（独占和共享）和等待队列中的后续节点共用同一个字段 */
Node nextWaiter;

/** 获取同步状态的线程 */
volatile Thread thread;

}

waitStatus 字段，等待状态，用来控制线程的阻塞和唤醒，并且可以避免不必要的调用LockSupport的 #park(...) 和 #unpark(...) 方法。。目前有 4 种：CANCELLED SIGNAL CONDITION PROPAGATE 。

 实际上，有第 5 种，INITAL ，值为 0 ，初始状态。

 thread 字段，Node 节点对应的线程 Thread 。

 #acquire(int arg) 方法，为 AQS 提供的模板方法。该方法为独占式获取同步状态，但是该方法对中断不敏感。也就是说，由于线程获取同步状态失败而加入到 CLH 同步队列中，后续对该线程进行中断操作时，线程不会从 CLH 同步队列中移除。代码如下：

1: public final void acquire(int arg) {
2:     if (!tryAcquire(arg) &&
3:         acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
4:         selfInterrupt();
5: } 

第 2 行：调用 #tryAcquire(int arg) 方法，去尝试获取同步状态，获取成功则设置锁状态并返回 true ，否则获取失败，返回 false 。若获取成功，#acquire(int arg) 方法，直接返回，不用线程阻塞，自旋直到获得同步状态成功。

#tryAcquire(int arg) 方法，需要自定义同步组件自己实现，该方法必须要保证线程安全的获取同步状态。代码如下：

protected boolean tryAcquire(int arg) {
throw new UnsupportedOperationException();
}

第 3 行：如果 #tryAcquire(int arg) 方法返回 false ，即获取同步状态失败，则调用 #addWaiter(Node mode) 方法，将当前线程加入到 CLH 同步队列尾部。并且， mode 方法参数为 Node.EXCLUSIVE ，表示独占模式。

第 3 行：调用 boolean #acquireQueued(Node node, int arg) 方法，自旋直到获得同步状态成功。详细解析，见下文#acquireQueued中。另外，该方法的返回值类型为 boolean ，当返回 true 时，表示在这个过程中，发生过线程中断。但是呢，这个方法又会清理线程中断的标识，所以在种情况下，需要调用【第 4 行】的 #selfInterrupt() 方法，恢复线程中断的标识，代码如下：

static void selfInterrupt() {

Thread.currentThread().interrupt();

}

 #acquireQueued(Node node, int arg) 方法，为一个自旋的过程，也就是说，当前线程（Node）进入同步队列后，就会进入一个自旋的过程，每个节点都会自省地观察，当条件满足，获取到同步状态后，就可以从这个自旋过程中退出，否则会一直执行下去。

 1: final boolean acquireQueued(final Node node, int arg) {
2:     // 记录是否获取同步状态成功
3:     boolean failed = true;
4:     try {
5:         // 记录过程中，是否发生线程中断
6:         boolean interrupted = false;
7:         /*
8:          * 自旋过程，其实就是一个死循环而已
9:          */
10:         for (;;) {
11:             // 当前线程的前驱节点
12:             final Node p = node.predecessor();
13:             // 当前线程的前驱节点是头结点，且同步状态成功
14:             if (p == head && tryAcquire(arg)) {
15:                 setHead(node);
16:                 p.next = null; // help GC
17:                 failed = false;
18:                 return interrupted;
19:             }
20:             // 获取失败，线程等待--具体后面介绍
21:             if (shouldParkAfterFailedAcquire(p, node) &&
22:                     parkAndCheckInterrupt())
23:                 interrupted = true;
24:         }
25:     } finally {
26:         // 获取同步状态发生异常，取消获取。
27:         if (failed)
28:             cancelAcquire(node);
29:     }
30: }

第 3 行：failed 变量，记录是否获取同步状态成功。

第 6 行：interrupted 变量，记录获取过程中，是否发生线程中断。

========== 第 7 至 24 行：“死”循环，自旋直到获得同步状态成功。==========

第 12 行：调用 Node#predecessor() 方法，获得当前线程的前一个节点 p 。

第 14 行：p == head 代码块，若满足，则表示当前线程的前一个节点为头节点，因为 head 是最后一个获得同步状态成功的节点，此时调用 #tryAcquire(int arg) 方法，尝试获得同步状态。? 在 #acquire(int arg) 方法的【第 2 行】，也调用了这个方法。

第 15 至 18 行：当前节点( 线程 )获取同步状态成功：

第 15 行：设置当前节点( 线程 )为新的 head 。

第 16 行：设置老的头节点 p 不再指向下一个节点，让它自身更快的被 GC 。

第 17 行：标记 failed = false ，表示获取同步状态成功。

第 18 行：返回记录获取过程中，是否发生线程中断。

第 20 至 24 行：获取失败，线程等待唤醒，从而进行下一次的同步状态获取的尝试

第 21 行：调用 #shouldParkAfterFailedAcquire(Node pre, Node node) 方法，判断获取失败后，是否当前线程需要阻塞等待。

========== 第 26 至 29 行：获取同步状态的过程中，发生异常，取消获取。==========

第 28 行：调用 #cancelAcquire(Node node) 方法，取消获取同步状态

 1: private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
2:     // 获得前一个节点的等待状态
3:     int ws = pred.waitStatus;
4:     if (ws == Node.SIGNAL) //  Node.SIGNAL
5:         /*
6:          * This node has already set status asking a release
7:          * to signal it, so it can safely park.
8:          */
9:         return true;
10:     if (ws > 0) { // Node.CANCEL
11:         /*
12:          * Predecessor was cancelled. Skip over predecessors and
13:          * indicate retry.
14:          */
15:         do {
16:             node.prev = pred = pred.prev;
17:         } while (pred.waitStatus > 0);
18:         pred.next = node;
19:     } else { // 0 或者 Node.PROPAGATE
20:         /*
21:          * waitStatus must be 0 or PROPAGATE.  Indicate that we
22:          * need a signal, but don't park yet.  Caller will need to
23:          * retry to make sure it cannot acquire before parking.
24:          */
25:         compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
26:     }
27:     return false;
28: }

pred 和 node 方法参数，传入时，要求前者必须是后者的前一个节点。

第 3 行：获得前一个节点( pre )的等待状态。下面会根据这个状态有三种情况的处理。

第 4 至 9 行：等待状态为 Node.SIGNAL 时，表示 pred 的下一个节点 node 的线程需要阻塞等待。在 pred 的线程释放同步状态时，会对 node 的线程进行唤醒通知。所以，【第 9 行】返回 true ，表明当前线程可以被 park，安全的阻塞等待。

第 19 至 26 行：等待状态为 0 或者 Node.PROPAGATE 时，通过 CAS 设置，将状态修改为 Node.SIGNAL ，即下一次重新执行 #shouldParkAfterFailedAcquire(Node pred, Node node) 方法时，满足【第 4 至 9 行】的条件。

但是，对于本次执行，【第 27 行】返回 false 。

另外，等待状态不会为 Node.CONDITION ，因为它用在 ConditonObject 中。

第 10 至 18 行：等待状态为 NODE.CANCELLED 时，则表明该线程的前一个节点已经等待超时或者被中断了，则需要从 CLH 队列中将该前一个节点删除掉，循环回溯，直到前一个节点状态 <= 0 。

对于本次执行，【第 27 行】返回 false ，需要下一次再重新执行 #shouldParkAfterFailedAcquire(Node pred, Node node) 方法，看看满足哪个条件。

整个过程如下图：

三：总结

 通过阅读AQS源码，能够相对synchronized更透彻的了解如何通过程序控制线程的同步，且在AQS中当线程没有获取到同步状态，并不会让线程立马切换到内核态的线程阻塞，而是通过控制Node节点的等待状态且CAS自旋获取同步状态。