并发AQS同步器

一.AQS容器架构

AQS同步器拥有首节点（head）和尾节点（tail）。同步队列的基本结构如下：

队列的基本操作有:

1. 未获取到锁的线程加入同步队列(同步队列设置尾节点):
   同步器AQS中包含两个节点类型的引用：一个指向头结点的引用（head),一个指向尾节点的引用（tail），当一个线程成功的获取到锁（同步状态），其他线程无法获取到锁，而是被构造成节点（包含当前线程，等待状态）加入到同步队列中等待获取到锁的线程释放锁。这个加入队列的过程，必须要保证线程安全。否则如果多个线程的环境下，可能造成添加到队列等待的节点顺序错误，或者数量不对。因此同步器提供了CAS原子的设置尾节点的方法（保证一个未获取到同步状态的线程加入到同步队列后，下一个未获取的线程才能够加入）。 如下图，设置尾节点：
   

2. 原头节点释放锁，唤醒后继节点(同步队列设置首节点)：
   同步队列遵循FIFO，头节点是获取锁（同步状态）成功的节点，头节点在释放同步状态的时候，会唤醒后继节点，而后继节点将会在获取锁（同步状态）成功时候将自己设置为头节点。设置头节点是由获取锁（同步状态）成功的线程来完成的，由于只有一个线程能够获取同步状态，则设置头节点的方法不需要CAS保证，只需要将头节点设置成为原首节点的后继节点 ，并断开原头结点的next引用。如下图，设置首节点：
   
   　
   这个同步队列维护了一个volatile int state（代表共享资源）和一个FIFO线程等待队列（多线程争用资源被阻塞时会进入此队列）。这里volatile是核心关键词，具体volatile的语义，在此不述。state的访问方式有三种:
   a. getState()
   b. setState()
   c. compareAndSetState()
   　AQS定义两种资源共享方式：Exclusive（独占，只有一个线程能执行，如ReentrantLock）和Share（共享，多个线程可同时执行，如Semaphore/CountDownLatch）。
   　不同的自定义同步器争用共享资源的方式也不同。自定义同步器在实现时只需要实现共享资源state的获取与释放方式即可，至于具体线程等待队列的维护（如获取资源失败入队/唤醒出队等），AQS已经在顶层实现好了。自定义同步器实现时主要实现以下几种方法：

   1. isHeldExclusively()：该线程是否正在独占资源。只有用到condition才需要去实现它。
   2. tryAcquire(int)：独占方式。尝试获取资源，成功则返回true，失败则返回false。
   3. tryRelease(int)：独占方式。尝试释放资源，成功则返回true，失败则返回false。
   4. tryAcquireShared(int)：共享方式。尝试获取资源。负数表示失败；0表示成功，但没有剩余可用资源；正数表示成功，且有剩余资源。
   5. tryReleaseShared(int)：共享方式。尝试释放资源，成功则返回true，失败则返回false。
      　
      　

二.AQS同步状态

AQS采用的是CLH队列，CLH队列是由一个一个结点构成的，前面提到结点中有一个状态位，这个状态位与线程状态密切相关，这个状态位(waitStatus)是一个32位的整型常量，它的取值如下：

1.static final int CANCELLED =  1;  2.static final int SIGNAL    = -1;  3.static final int CONDITION = -2;  4.static final int PROPAGATE = -3;  

下面解释一下每个值的含义
CANCELLED：因为超时或者中断，结点会被设置为取消状态，被取消状态的结点不应该去竞争锁，只能保持取消状态不变，不能转换为其他状态。处于这种状态的结点会被踢出队列，被GC回收；
SIGNAL：表示这个结点的继任结点被阻塞了，到时需要通知它；
CONDITION：表示这个结点在条件队列中，因为等待某个条件而被阻塞；
PROPAGATE：使用在共享模式头结点有可能牌处于这种状态，表示锁的下一次获取可以无条件传播；
0：None of the above，新结点会处于这种状态。

三.获取锁

AQS中比较重要的两个操作是获取和释放，以下是各种获取操作:

1.public final void acquire(int arg);  2.public final void acquireInterruptibly(int arg);  3.public final void acquireShared(int arg);  4.public final void acquireSharedInterruptibly(int arg);  5.protected boolean tryAcquire(int arg);   6.protected int tryAcquireShared(int arg);  7.public final boolean tryAcquireNanos(int arg, long nanosTimeout) throws InterruptedException;  public final boolean tryAcquireSharedNanos(int arg, long nanosTimeout) throws InterruptedException;      

获取操作的流程图如下：

1、如果尝试获取锁成功整个获取操作就结束，否则转到2. 尝试获取锁是通过方法tryAcquire来实现的，AQS中并没有该方法的具体实现，只是简单地抛出一个不支持操作异常，在AQS简介中谈到tryAcquire有很多实现方法，这里不再细化，只需要知道如果获取锁成功该方法返回true即可；

2、如果获取锁失败，那么就创建一个代表当前线程的结点加入到等待队列的尾部，是通过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）就设置当前结点为队尾结点，返回；
如果没有元素（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;              }          }      }  }  

enq方法采用的是变种CLH算法，先看头结点是否为空，如果为空就创建一个傀儡结点，头尾指针都指向这个傀儡结点，这一步只会在队列初始化时会执行；
如果头结点非空，就采用CAS操作将当前结点插入到头结点后面，如果在插入的时候尾结点有变化，就将尾结点向后移动直到移动到最后一个结点为止，然后再把当前结点插入到尾结点后面，尾指针指向当前结点，入队成功。

3、将新加入的结点放入队列之后，这个结点有两种状态，要么获取锁，要么就挂起，如果这个结点不是头结点，就看看这个结点是否应该挂起，如果应该挂起，就挂起当前结点，是否应该挂起是通过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;     }  

该方法首先检查前趋结点的waitStatus位，如果为SIGNAL,表示前趋结点会通知它，那么它可以放心大胆地挂起了；

如果前趋结点是一个被取消的结点怎么办呢？那么就向前遍历跳过被取消的结点，直到找到一个没有被取消的结点为止，将找到的这个结点作为它的前趋结点，将找到的这个结点的waitStatus位设置为SIGNAL,返回false表示线程不应该被挂起。
上面谈的不是头结点的情况决定是否应该挂起，是头结点的情况呢？
是头结点的情况，当前线程就调用tryAcquire尝试获取锁，如果获取成功就将头结点设置为当前结点，返回；如果获取失败就循环尝试获取锁，直到获取成功为止。整个acquire过程就分析完了。
我再用流程图总结一下：

四. 释放锁

释放操作有以下方法:

1.public final boolean release(int arg);   2.protected boolean tryRelease(int arg);   3.protected boolean tryReleaseShared(int arg); 

下面看看release方法的实现过程
1、release过程比acquire要简单，首先调用tryRelease释放锁，如果释放失败，直接返回；
2、释放锁成功后需要唤醒继任结点，是通过方法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);     }  

1、node参数传进来的是头结点，首先检查头结点的waitStatus位，如果为负，表示头结点还需要通知后继结点，这里不需要头结点去通知后继，因此将该该标志位清0.
2、然后查看头结点的下一个结点，如果下一个结点不为空且它的waitStatus<=0,表示后继结点没有被取消，是一个可以唤醒的结点，于是唤醒后继结点返回；如果后继结点为空或者被取消了怎么办？寻找下一个可唤醒的结点，然后唤醒它返回。
这里并没有从头向尾寻找，而是相反的方向寻找，为什么呢？
因为在CLH队列中的结点随时有可能被中断，被中断的结点的waitStatus设置为CANCEL,而且它会被踢出CLH队列，如何个踢出法，就是它的前趋结点的next并不会指向它，而是指向下一个非CANCEL的结点,而它自己的next指针指向它自己。一旦这种情况发生，如何从头向尾方向寻找继任结点会出现问题，因为一个CANCEL结点的next为自己，那么就找不到正确的继任接点。
有的人又会问了，CANCEL结点的next指针为什么要指向它自己，为什么不指向真正的next结点？为什么不为NULL？
第一个问题的答案是这种被CANCEL的结点最终会被GC回收，如果指向next结点，GC无法回收。
对于第二个问题的回答，JDK中有这么一句话： The next field of cancelled nodes is set to point to the node itself instead of null, to make life easier for isOnSyncQueue.大至意思是为了使isOnSyncQueue方法更新简单。isOnSyncQueue方法判断一个结点是否在同步队列，实现如下：

final boolean isOnSyncQueue(Node node) {      if (node.waitStatus == Node.CONDITION || node.prev == null)          return false;      if (node.next != null) // If has successor, it must be on queue          return true;      /*      * node.prev can be non-null, but not yet on queue because      * the CAS to place it on queue can fail. So we have to      * traverse from tail to make sure it actually made it.  It      * will always be near the tail in calls to this method, and      * unless the CAS failed (which is unlikely), it will be      * there, so we hardly ever traverse much.      */      return findNodeFromTail(node);  }  

如果一个结点next不为空，那么它在同步队列中，如果CANCEL结点的后继为空那么CANCEL结点不在同步队列中，这与事实相矛盾。因此将CANCEL结点的后继指向它自己是合理的选择。

五. AQS在各同步器内的Sync与State实现

1、什么是state机制：
提供 volatile 变量 state; 用于同步线程之间的共享状态。通过 CAS 和 volatile 保证其原子性和可见性。对应源码里的定义：

/**   * 同步状态   */    private volatile int state;    /**   *cas   */    protected final boolean compareAndSetState(int expect, int update) {        // See below for intrinsics setup to support this        return unsafe.compareAndSwapInt(this, stateOffset, expect, update);    }    

2、不同实现类的Sync与State：
基于AQS构建的Synchronizer包括ReentrantLock,Semaphore,CountDownLatch, ReetrantRead WriteLock,FutureTask等，这些Synchronizer实际上最基本的东西就是原子状态的获取和释放，只是条件不一样而已。

a. ReentrantLock
需要记录当前线程获取原子状态的次数，如果次数为零，那么就说明这个线程放弃了锁（也有可能其他线程占据着锁从而需要等待），如果次数大于1，也就是获得了重进入的效果，而其他线程只能被park住，直到这个线程重进入锁次数变成0而释放原子状态。ReetranLock可以通过FairSync的tryAcquire实现:
state初始化为0，表示未锁定状态。A线程lock()时，会调用tryAcquire()独占该锁并将state+1。此后，其他线程再tryAcquire()时就会失败，直到A线程unlock()到state=0（即释放锁）为止，其它线程才有机会获取该锁。当然，释放锁之前，A线程自己是可以重复获取此锁的（state会累加），这就是可重入的概念。但要注意，获取多少次就要释放多么次，这样才能保证state是能回到零态的。

b. Semaphore
则是要记录当前还有多少次许可可以使用，到0，就需要等待，也就实现并发量的控制，Semaphore一开始设置许可数为1，实际上就是一把互斥锁。Semaphore可以用FairSync实现。

c. CountDownLatch
闭锁则要保持其状态，在这个状态到达终止态之前，所有线程都会被park住，闭锁可以设定初始值，这个值的含义就是这个闭锁需要被countDown()几次，因为每次CountDown是sync.releaseShared(1),而一开始初始值为10的话，那么这个闭锁需要被countDown()十次，才能够将这个初始值减到0，从而释放原子状态，让等待的所有线程通过。

d. FutureTask
需要记录任务的执行状态，当调用其实例的get方法时,内部类Sync会去调用AQS的acquireSharedInterruptibly()方法，而这个方法会反向调用Sync实现的tryAcquireShared()方法，即让具体实现类决定是否让当前线程继续还是park,而FutureTask的tryAcquireShared方法所做的唯一事情就是检查状态，如果是RUNNING状态那么让当前线程park。而跑任务的线程会在任务结束时调用FutureTask 实例的set方法（与等待线程持相同的实例），设定执行结果，并且通过unpark唤醒正在等待的线程，返回结果。

---

参考文章
Java多线程（七）之同步器基础：AQS框架深入分析
Java并发AQS之详解