AQS（AbstractQueuedSynchronizer）抽象队列式同步器，从它的名字中，我们可以看出AQS本身是一个同步器，也就是发生资源竞争时，用来同步的工具。它的内部使用了队列来进行实现，而之所以叫“抽象”，是因为AQS只是一个“框架”，它提供了当发生资源竞争时，竞争失败的线程入队、出队等的方式，但没有描述竞争的具体细节，这些交由其子类来按需具体实现，AQS在JUC中许多大名鼎鼎的类中得到应用，例如ReentrantLock，CountDownLatch，Semaphore等等，可以说，AQS是JUC的基石，搞懂了AQS，就能轻松理解JUC中各种锁的api。
一. 概念
AQS的模型：
AQS在内部维护定义了一个内部类Node，用它来构建一个FIFO的双向链表，分别有Head和Tail来指向链表头尾，基于这样一套数据结构，形成了基于逻辑队列非线程饥饿的一种自旋公平锁，称为CLH锁。（由于是 Craig、Landin 和 Hagersten三位大佬的发明，因此命名为CLH锁，CLH锁是一种基于链表的可扩展、高性能、公平的自旋锁，申请线程只在本地变量上自旋，它不断轮询前驱的状态，如果发现前驱释放了锁就结束自旋）。如果说AQS是JUC的基石，那么CLH就是AQS的基石。
AQS将资源的共享方式定义为两种：1.Exclusive 独占，即只有一个线程可以访问资源。2. Share 共享，即允许同时有X个线程访问资源。AQS使用一个被volatile修饰的int变量state来代表资源。
针对两种共享方式，子类需要继承AQS，并分别实现不同的接口，主要是如下几个：
Exclusive：
tryAcquire: 尝试获取资源，成功返回true，失败返回false。
tryRelease: 尝试释放资源，成功返回true，失败返回false。
Share:
tryAcquireShared: 尝试获取资源，返回负数表示失败，0表示成功，但没有资源可用，正数表示成功，而且有剩余资源。
tryReleaseShared: 尝试释放资源，如果释放后允许唤醒后需等待的线程，则返回true，否则返回false。
以上四个方法，都有一个int参数，AQS没有明确说明这个参数的含义，可以由子类来定义。一般来讲，对于一个继承AQS的锁（同步器）而言，要么实现独占锁，要么实现共享锁，但也有同时实现这两种的，如ReentrantReadWriteLock。为了减轻开发者不必要的工作，上述的四个方法都没有设计成抽象方法，也就是说子类只需要按需实现即可，对于子类未实现，却又被调用了的方法，AQS默认会抛出一个UnsupportedOperationException异常。
典型的独占锁是ReentrantLock，state初始时默认为0，表示资源还没有被获取，当有一个线程调用lock时，lock底层会调用tryAcquire，即独占该资源，并将state + 1，此后这个线程可以重复lock，state也会递增，只有当这个线程调用unlock（底层是tryRelease）至state为0时，其他线程才有机会获得这个资源，这就是可重入的概念，所以ReentrantLock称为可重入锁，它的本质仍是一个独占锁。
下边，我们分别从独占模式和共享模式来描述AQS的执行原理。
二. 独占模式
-
acquire
acquire是独占模式下，AQS用来尝试获取资源的方法，可以想象的是，它的实现一定是调用了上文提到的tryAcquire：
public final void acquire(int arg) {
if(!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
这段代码的主要流程与含义如下：
1.调用tryAcquire尝试获取资源，如果获取成功，这个方法会直接返回。
2.如果获取失败，则首先调用addWaiter，以独占模式将当前线程包装成一个Node，将它放置到CLH的末尾。
3.再调用acquireQueued，不断自旋尝试获取资源，直到获取成功，当获取成功时，会返回false，此时整个方法也会直接返回。但当自旋过程中发生线程中断时，不会立即响应中断，而是在获取资源成功后，返回一个true，此时selfInterrupt被激活，自行补一个中断。
下面我们细节看一下上边用到的addWaiter，acquireQueued方法：
addWaiter：
private Node addWaiter(Node mode)
{
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;
}
这里首先将当前线程按照执行模式构造成了一个Node，然后先尝试通过快速的方式将Node加入队尾，当快速加入失败后，则会调用enq方法进行加入，最后返回当前线程所在的Node。下面看enq方法的实现：
private Node enq(final Node node)
{
for (;;)
{
Node t = tail;
if (t == null)
{
if (compareAndSetHead(new Node()))
tail = head;
}
else
{
node.prev = t;
if (compareAndSetTail(t, node))
{
t.next = node;
return t;
}
}
}
}
这是一段非常经典的用法，即CAS自旋volitale变量，首先判断CLH的tail是否为null，如果是null就初始化一个进去。这样做，是因为在AQS中，需要依赖前驱节点将自己唤醒，如果没有前驱，当前节点会永远无法唤醒。再次自旋时，就可以将当前Node放置在新创建的tail后，为防止高并发下tail可能变化的问题，这里通过compareAndSetTail先尝试将Node加入tail后，如果失败了，意味着有线程抢先变化了tail，下一次自旋会再次获取新的tail，再次尝试加入队尾，直到成功。类似的用法可以参考AtomicInteger.getAndIncrement()。compareAndSetTail是Unsafe类里提供的一个方法，底层是native函数，通过CPU原语实现的CAS操作。
通过以上步骤，我们的线程由于没有拿到资源，已经被包装成一 个Node加入了CLH的尾部，下边要做的事就是等待前置线程释放资源、自己被唤醒了，即acquireQueued方法做的事：
final boolean acquireQueued(final Node node, int arg)
{
boolean failed = true;// 标记是否成功拿到资源
try
{
boolean interrupted = false;// 标记等待过程中是否被中断过
for (;;)
{
final Node p = node.predecessor();// 拿到前驱
// 如果前驱是head，即该结点已成老二，那么便可以尝试获取资源（因为此时head可能已经释放了资源）。
if (p == head && tryAcquire(arg))
{
setHead(node);// 拿到资源后，将head指向该结点，同时会将node.prev置为null。
p.next = null; // 再将head.next置为null，就是为了方便GC回收以前的head结点。也就意味着之前拿完资源的结点出队了
failed = false;
return interrupted;// 返回等待过程中是否被中断过
}
// 如果自己可以休息了，就进入waiting状态，直到被unpark()
if (shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt())
interrupted = true;// 如果等待过程中被中断过，就将interrupted标记为true
}
}
finally
{
if (failed)
cancelAcquire(node);
}
}
在梳理整个流程前，我们还应该了解下shouldParkAfterFailedAcquire方法和parkAndCheckInterrupt方法：
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node)
{
int ws = pred.waitStatus;// 拿到前驱的状态
if (ws == Node.SIGNAL)
// 如果前驱已经是SIGNAL状态，那就可以安心休息了
return true;
if (ws > 0)
{
/*
* 如果前驱放弃了，那就一直往前找，直到找到最近一个正常等待的状态，并排在它的后边。
* 注意：那些放弃的结点，由于被自己“加塞”到它们前边，它们相当于形成一个无引用链，稍后就会被GC
*/
do
{
node.prev = pred = pred.prev;
}
while (pred.waitStatus > 0);
pred.next = node;
}
else
{
// 如果前驱正常，那就把前驱的状态设置成SIGNAL。有可能失败，因为前驱有可能刚释放完
compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
}
return false;
}
private final boolean parkAndCheckInterrupt()
{
LockSupport.park(this);// 调用park()使线程进入waiting状态
return Thread.interrupted();// 如果被唤醒，查看自己是不是被中断的。
}
可见，这两个方法的作用就是向前寻找一个最近的、状态为SIGNAL的节点，将自己排在它的后边，然后将当前线程置为等待状态，如果被唤醒，会确认下是不是被中断的。关于这个状态，我们目前只需要知道，Node有四种状态，当当前Node的状态为SIGNAL，在他释放资源时，会唤醒其最近的、未放弃的一个后续节点（unpark），这意味着排队中的节点，是可能因为各种原因放弃的，但他们仍在队伍中。
看完这两个方法，我们就可以梳理acquireQueued的流程了：
1.调用tryAcquire尝试获取资源，成功则就直接返回，不成功则调用addWaiter将线程包装成一个Node排在CLH队尾。
2.调用acquireQueued在CLH中找到一个最近的安全点（即状态为SIGNAL的节点），把自己排在它后边，然后将线程状态置为waiting，即开始休息。
3.一旦线程被唤醒（排到第二名了，或者被中断了），就尝试去竞争资源，获取到资源后才会返回。如果整个等待过程中线程被中断过，则返回true，反之返回false。
4.如果线程等待过程中被中断过，拿到资源后会把中断补上。
梳理下acquire整个流程：
实际上，这也正是ReentrantLock.lock()的流程，整个lock函数，其实就是一个acquire(1)。
- release
release是AQS中用于释放资源的操作，他是acquire的反操作，如果资源彻底被释放了（state = 0）它会唤醒后继节点。
下边是release源码：
public final boolean release(int arg)
{
if (tryRelease(arg))
{
Node h = head;// 找到头结点
if (h != null && h.waitStatus != 0)
unparkSuccessor(h);// 唤醒等待队列里的下一个线程
return true;
}
return false;
}
首先通过调用tryRelease来实现释放资源，如果返回true，则认为释放成功，尝试唤醒后续节点。需要注意的是，如果子类是可重入锁，那么一定要确认state = 0时才能返回true！否则就会出现，明明可重入锁还没有完全释放，后续节点却被唤醒了的情况。
这里我们唯一需要看细节的，是unparkSuccessor方法，它用于在当前节点释放资源后，唤醒后续节点：
private void unparkSuccessor(Node node)
{
// node一般为当前线程所在的结点。
int ws = node.waitStatus;
if (ws < 0)// 置零当前线程所在的结点状态，允许失败。
compareAndSetWaitStatus(node, ws, 0);
Node s = node.next;// 找到下一个需要唤醒的结点s
if (s == null || s.waitStatus > 0)
{// 如果为空或已取消
s = null;
for (Node t = tail; t != null && t != node; t = t.prev)
if (t.waitStatus <= 0)// <=0的结点，都是还有效的结点。
s = t;
}
if (s != null)
LockSupport.unpark(s.thread);// 唤醒
}
这里的逻辑并不复杂，就是用unpark唤醒最前边的有效节点，需要注意的是，它是从tail开始向前寻找的，直到找到那个离当前节点最近的、有效的节点。被唤醒以后，就会继续走acquireQueued的逻辑了，一般来讲，这个有效节点就是当前节点的next，如果真的出现中间有无效节点，也没关系，有效节点被唤醒后，会再次尝试向前找安全点，就会把自己放置到当前节点后，下一轮自旋时，就会被顺利激活。
三.共享模式
1.acquireShared
这是共享模式下，用于获取资源的方法，获取成功则直接返回，失败则进入队列：
public final void acquireShared(int arg)
{
if (tryAcquireShared(arg) < 0)
doAcquireShared(arg);
}
tryAcquireShared同样是需要子类自己实现的，但这里AQS其实定义好了返回值的语意，负数代表失败，0代表获取成功但没有剩余资源，正数代表成功且有剩余资源。这里我们唯一需要看的是doAcquireShared，它对应独占模式下的acquireQueued方法。
private void doAcquireShared(int arg)
{
final Node node = addWaiter(Node.SHARED);// 加入队列尾部
boolean failed = true;// 是否成功标志
try
{
boolean interrupted = false;// 等待过程中是否被中断过的标志
for (;;)
{
final Node p = node.predecessor();// 前驱
if (p == head)
{// 如果到head的下一个，因为head是拿到资源的线程，此时node被唤醒，很可能是head用完资源来唤醒自己的
int r = tryAcquireShared(arg);// 尝试获取资源
if (r >= 0)
{// 成功
setHeadAndPropagate(node, r);// 将head指向自己，还有剩余资源可以再唤醒之后的线程
p.next = null; // help GC
if (interrupted)// 如果等待过程中被打断过，此时将中断补上。
selfInterrupt();
failed = false;
return;
}
}
// 判断状态，寻找安全点，进入waiting状态，等着被unpark()或interrupt()
if (shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt())
interrupted = true;
}
}
finally
{
if (failed)
cancelAcquire(node);
}
}
可以看到和acquireQueued区别不大，只有两点差异：1.在竞争资源时，会调用setHeadAndPropagate，唤醒自己后，如果还有剩余资源，则会继续唤醒后续节点。2.处理中断的位置与acquireQueued不同。
我们重点看下setHeadAndPropagate函数：
private void setHeadAndPropagate(Node node, int propagate)
{
Node h = head;
setHead(node);// head指向自己
// 如果还有剩余量，继续唤醒下一个线程
if (propagate > 0 || h == null || h.waitStatus < 0)
{
Node s = node.next;
if (s == null || s.isShared())
doReleaseShared();
}
}
可以看出，流程上是先唤醒自己，再唤醒后续节点，也就是说，如果当前剩余资源不足以唤醒自己，即便能够满足后续线程使用，也不会跳过当前线程，而是严格按照FIFO。doReleaseShared方法，则是唤醒后继节点的方法，我们把它放在releaseShared方法中讲。
2.releaseShared
这是共享模式下释放资源的方法，是acquireShared的反操作：
public final boolean releaseShared(int arg)
{
if (tryReleaseShared(arg))
{// 尝试释放资源
doReleaseShared();// 唤醒后继结点
return true;
}
return false;
}
同样的逻辑，先调用子类的tryReleaseShared尝试释放资源，释放成功后，调用doReleaseShared唤醒后继节点。
跟独占模式下的release()相似，但有一点稍微需要注意：独占模式下的tryRelease()在完全释放掉资源（state=0）后，才会返回true去唤醒其他线程，这主要是基于独占下可重入的考量；而共享模式下的releaseShared()则没有这种要求，共享模式实质就是控制一定量的线程并发执行，那么拥有资源的线程在释放掉部分资源时就可以唤醒后继等待结点。例如，资源总量是13，A（5）和B（7）分别获取到资源并发运行，C（4）来时只剩1个资源就需要等待。A在运行过程中释放掉2个资源量，然后tryReleaseShared(2)返回true唤醒C，C一看只有3个仍不够继续等待；随后B又释放2个，tryReleaseShared(2)返回true唤醒C，C一看有5个够自己用了，然后C就可以跟A和B一起运行。
但这也不是绝对的，如ReentrantReadWriteLock中读锁的tryReleaseShared()只有在完全释放掉资源（state=0）才返回true，所以自定义同步器可以根据需要决定tryReleaseShared()的返回值。
下边看下doReleaseShared细节：
private void doReleaseShared()
{
for (;;)
{
Node h = head;
if (h != null && h != tail)
{
int ws = h.waitStatus;
if (ws == Node.SIGNAL)
{
if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
continue;
unparkSuccessor(h);// 唤醒后继
}
else if (ws == 0 && !compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
continue;
}
if (h == head)// head发生变化
break;
}
}
与独占模式差不多。
290
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
