AbstractQueuedSynchronizer源码剖析（五）- 响应中断的共享锁

1、AbstactQueuedSynchronizer的基本数据结构

AbstractQueuedSynchronizer是并发类的重中之重，我会细分很多章节来解析。本篇博客主要分析AQS中的不响应中断的独占锁。

(1). AbstactQueuedSynchronizer的基本数据结构

AQS的基本数据结构为Node，关于Node，JDK作者写了详细的注释，这里我大致总结几点：
1.1 AbstractQueuedSynchronizer的等待队列是CLH队列的变种，CLH队列通常用于自旋锁，AQS中的CLH可以简单的理解为“等待锁的线程队列”。

1.2 每个节点中持有一个名为"status"的字段用于一条线程是否应当阻塞的追踪。
1.3 一条线程所在节点如果它处于队列头的下一个节点，那么它会尝试去acquire。因为头节点是一个dummy节点，也就是说头节点不持有任何线程。所以，一条线程所在节点如果它处于队列头节点的下一个节点，那么他会尝试去acquire，但是并不保证成功。
1.4 要进入队列，你只需要自动将它拼接在队列尾部即可；如果获取了锁，你只需要设置header字段即可。

下面我用一张表格总结一下Node中持有哪些变量且每个变量的含义：

关于SIGNAL、CANCELLED、CONDITION、PROPAGATE四个状态，JDK源码的注释中同样有了详细的解读，再用一张表格总结一下：

2、在“响应中断的共享锁”模式下AbstractQueuedSynchronizer供子类实现的方法

AbstractQueuedSynchzonizer是基于模板模式的实现，不过它的模板模式写法有点特别，整个类中没有任何一个abstract的抽象方法，取而代之的是，需要子类去实现的那些方法通过一个方法体抛出异常来让子类知道。

tryAcquireShared(int)：共享方式。尝试获取资源。负数表示失败；0表示成功，但没有剩余可用资源；正数表示成功，且有剩余资源。

tryReleaseShared(int)：共享方式。尝试释放资源，如果释放后允许唤醒后续等待结点返回true，否则返回false。

在这里，读者应该清楚的知道，为什么AQS需要我们去实现这些方法(在这里，我只仅仅说明的是“不响应中断的共享锁”)？在上一篇博客中，我已经提到过，其实AQS只是定义了一个流程而已，关于具体如何获取锁，需要子类实现。

(1). 下面我贴出AQS中的一段代码你就可以明白:

这段代码描述的大概意思如下：

以共享的方式去获取锁，忽略中断响应。一旦{@link #tryAcquireShared}方法执行成功就证明当前线程获取到了锁。子类应该去定制{@link #tryAcquireShared}方法的具体实现。

(2). 下面我贴出AQS中的一段代码你就可以明白:

这段代码描述的大概意思如下：

以共享的方式去释放锁，忽略中断响应。一旦{@link #tryReleaseShared}方法执行成功就证明当前线程释放了锁。子类应该去定制{@link #tryReleaseShared}方法的具体实现。

3、在“响应中断的共享锁”模式下AbstractQueuedSynchronizer获取锁的实现流程

在AQS中，“响应中断的共享锁”模式的获取锁的的入口是以下方法:

tryAcquireShared方法前面说过了，是子类实现的一个方法，tryAcquireShared是共享方式尝试获取资源。负数表示失败；0表示成功，但没有剩余可用资源；正数表示成功，且有剩余资源。如果tryAcquireShared返回的是负数，即表明当前线程获取锁失败，自然也就需要构建数据结构进行阻塞等待，此时需要进入到doAcquireSharedInterruptibly方法了。如果tryAcquireShared方法返回的是正数，那么当前线程已经获得了锁，则直接跳过，去执行自己的业务。

第一：如果tryAcquireShared返回的是负数, 那么流程会走doAcquireSharedInterruptibly方法：

我们知道，在当前我们分析的这种情况下，在方法内部，我们将当前线程封装成了一个Node.SHARED节点。构造完成之后，需要入队，即加入到“等待锁的线程队列CLH”中。如何入队？首先尝试的是快速入队。何为快速入队？直接把我们刚才构造的node的前驱指针指向当前尾节点，然后通过CAS操作把我们刚才构造的node作为新的尾节点，最后再把原来老的尾节点的后继指针指向现在的新的尾节点。说了那么多，那么快速入队的大前提是什么？那就是这个“等待锁的线程队列CLH”必须先存在。如果不存在，那么只能走常规的入队操作流程，也就是进入到enq(node)方法中。从这里我们也可以知道，其实enq(node)在AQS的整个生命周期中只会执行一次，因为只有第一次初始化“等待锁的线程队列CLH”才会走到这里，后来的入队都会走“快速入队”流程。 假设我们这里还没有 “等待锁的线程队列CLH”，即当前的tail节点为null，那么就会进入enq(node)方法。分析了这么多，其实这些代码的入口就是在第947行代码的逻辑，也就是说这一行代码执行完毕之后，当前线程已经被加入到CLH队列的尾部了。

下面我们看下enq(node)方法的源代码：

这段代码的逻辑为：
如果尾节点为空，即当前数据结构中没有节点，那么new一个不带任何状态的Node作为头节点，并且将head赋值给tail。如果尾节点不为空，那么并发下使用CAS算法将当前Node追加成为尾节点，由于是一个for(;;)循环，因此所有没有成功acquire的Node最终都会被追加到数据结构中。

情况一：通过doAcquireSharedInterruptibly方法的第985行代码可以看出，如果当前线程所在节点的前继节点是head节点，那么当前节点就再次的tryAcquireShared了一次。如果tryAcquireShared的返回值是大于等于0的，就证明当前线程成功的获取了共享锁，那么执行setHeadAndPropagate方法，将当前节点作为head、将当前节点中的thread设置为null、将当前节点的prev设置为null，这保证了数据结构中头结点永远是一个不带Thread的空节点。其中setHeadAndPropagate方法的第二个参数是tryAcquireShared方法的返回值，我们知道: 负数表示失败；0表示成功，但没有剩余可用资源；正数表示成功，且有剩余资源。

当大于0的时候，就证明我们现在共享锁的资源充足，可能目前有线程阻塞在队列中，我们需要去唤醒当前节点的下一个节点，这就是共享锁唤醒的传播性。

情况二：如果当前线程所在节点的前继节点不是head节点，那么它就需要判断自己需不需要进行阻塞了，因为至少到目前为止，它真的没有机会再去获取锁了。当前线程进行阻塞的大前提是，需要寻找一个前继节点的waitStatus为SIGNAL的节点，这是AQS约定的。只有自己节点的前继节点的waitStatus是SIGNAL，我这个节点才可以安心的去阻塞。因为我的前继节点的waitStatus是SIGNAL，就相当于我告诉了我的前继节点，我将要去阻塞了，到时候请唤醒我。

(1). 如果 当前节点的前驱节点的 waitStatus是SIGNAL，返回true，表示当前节点应当park。

这个时候就会调用parkAndCheckInterrupt()方法：

当前线程就会被阻塞住。从这个方法还可以看出，如果这个线程被唤醒了，这个线程自己会返回在它阻塞期间有没有被中断过。需要注意的是，Thread.interrupted()会清除当前线程的中断标记位。所以在这里我们可以明白，在doAcquireSharedInterruptibly方法的第996行中，如果这个线程被唤醒了，并且曾经在阻塞期间被中断过，就直接抛出了中断异常。

(2).如果当前节点的前驱节点的waitStatus>0，相当于CANCELLED（因为状态值里面只有CANCELLED是大于0的），那么CANCELLED的节点作废，当前节点不断向前找并重新连接为双向队列，直到找到一个前驱节点waitStats不是CANCELLED的并且最靠近head节点的那一个为止。它的前驱节点不是SIGNAL状态且waitStatus<=0，利用CAS机制把前驱节点的waitStatus更新为SIGNAL状态。在这种情况下parkAndCheckInterrupt返回的是false，也就是说当前节点持有的线程还是不死心，它还需要最后一次判断一下自己的前驱节点是不是head节点，如果是的话，就再一次的tryAcquireShared，这也是它最后的一次挣扎的机会了。如果这一次失败了，就必须进行阻塞。

4、在“响应中断的共享锁”模式下AbstractQueuedSynchronizer释放锁流程

这个释放流程和AbstractQueuedSynchronizer源码剖析（四）- 不响应中断的共享锁释放流程是一模一样的。此方法是共享模式下线程释放共享资源的顶层入口。它会释放指定量的资源，如果彻底释放了（即state=0）,它会唤醒等待队列里的其他线程来获取资源。下面是releaseShared的源码：

逻辑并不复杂。它调用tryReleaseShared来释放资源。有一点需要注意的是，它是根据tryReleaseShared的返回值来判断该线程是否已经完成释放掉资源了！所以自定义同步器在设计tryReleaseShared的时候要明确这一点！！正常来说，tryReleaseShared都会成功的,该线程来释放资源，那么它肯定已经拿到资源了，直接减掉相应量的资源即可(state-=arg)，也不需要考虑线程安全的问题。但要注意它的返回值，上面已经提到了，releaseShared是根据tryReleaseShared的返回值来判断该线程是否已经完成释放掉资源了！所以自定义同步器在实现时，如果已经彻底释放资源(state=0)，要返回true，否则返回false。如果没有彻底释放资源，也就是出现了重入的情况，需要多次释放。如果释放成功了，我们就需要唤醒head节点的下一个节点所持有的线程。基本逻辑如下:

1. 首先拿到head节点，判断head节点不等于null，并且head节点的waitStatus是不等于0的话，就去唤醒head节点的下一个节点所持有的线程。
2. 调用unparkSuccessor(Node node)方法唤醒head节点的下一个节点所持有的线程。

private void unparkSuccessor(Node node) {
        int ws = node.waitStatus;
        if (ws < 0)
            compareAndSetWaitStatus(node, ws, 0);
        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);
}