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的抽象方法，取而代之的是，需要子类去实现的那些方法通过一个方法体抛出异常来让子类知道。

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

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

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

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

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

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

tryAcquire方法前面说过了，是子类实现的一个方法，如果tryAcquire返回的是true，即表明当前线程获得了锁，自然也就不需要构建数据结构进行阻塞等待。如果tryAcquire方法返回的是false，那么当前线程没有获得锁，接着执行"doAcquireInterruptibly(int arg)"这句代码。所有的这一切都是基于当前线程没有被interrupted的。

第一：具体分析doAcquireInterruptibly(int arg)流程：

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

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

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

刚才我们分析了doAcquireInterruptibly(int arg)方法的第883行的代码流程，知道了当前线程已经被封装成了Node节点加入到了“等待锁的线程队列CLH”中了，但是当前线程目前还没有阻塞。那么它是什么时候应该阻塞呢？它在阻塞之前应该做些什么呢？下面我们具体分析。doAcquireInterruptibly(int arg)方法的第883行之后的代码。

情况一：通过第887行代码可以看出，如果当前线程所在节点的前继节点是head节点，那么当前节点就再次的tryAcquire了一次。如果当前线程所在节点tryAcquire成功了，那么执行setHead方法，将当前节点作为head、将当前节点中的thread设置为null、将当前节点的prev设置为null，这保证了数据结构中头结点永远是一个不带Thread的空节点。为什么需要判断当前线程所在节点的前继节点是head节点，就再次的去tryAcquire了一次呢？

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

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

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

当前线程就会被阻塞住。从这个方法还可以看出，如果这个线程被唤醒了，这个线程自己会返回在它阻塞期间有没有被中断过。需要注意的是，Thread.interrupted()会清除当前线程的中断标记位。所以在这里我们可以明白，在acquireQueued(final Node node, int arg)方法的第869行中，如果这个线程被唤醒了，并且曾经在阻塞期间被中断过，就将中断标识符interrupted置为true。接着线程又会进入acquireQueued(final Node node, int arg)的第859行for循环中。如果当前这个被唤醒的线程是正常被唤醒的，那么它的前继节点就应该是head，这个时候当前被唤醒的线程就会执行tryAcquire方法去获取锁。如果假设它获取锁成功了，那么它会把自己设置为head节点，并且把head节点的持有线程设置为null，以保持head节点是dummy节点，接着当前线程就去做自己的业务了。

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

(3).如果该节点所持有的线程被唤醒之后，会返回它是否在阻塞期间被中断过。如果被中断过，会在doAcquireInterruptibly(int arg)方法的在896抛出异常。

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

这一步和AbstractQueuedSynchronizer源码剖析（二）- 不响应中断的独占锁中的释放锁的流程是一模一样的。上一小节已经把acquire()说完了，这一小节就来讲讲它的反操作release()吧。此方法是独占模式下线程释放共享资源的顶层入口。它会释放指定量的资源，如果彻底释放了（即state=0）,它会唤醒等待队列里的其他线程来获取资源。下面是release()的源码：

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

1. 首先拿到head节点，判断head节点不等于null，并且head节点的waitStatus是不等于0的话，就去唤醒head节点的下一个节点所持有的线程。
2. 调用unparkSuccessor(Node node)方法唤醒head节点的下一个节点所持有的线程。这个函数并不复杂。一句话概括：用unpark()唤醒等待队列中最前边的那个未放弃的线程，这里我们也用s来表示吧。此时，再和acquireQueued()联系起来，s被唤醒后，进入if (p == head && tryAcquire(arg))的判断（即使p!=head也没关系，它会再进入shouldParkAfterFailedAcquire()寻找一个安全点。这里既然s已经是等待队列中最前边的那个未放弃的线程了，那么通过shouldParkAfterFailedAcquire()的调整，s也必然会跑到head的next结点，下一次自旋p==head就成立啦），然后s把自己设置成head标杆结点，表示自己已经获取到资源了，acquire()也返回了！