为什么AQS使用双向链表

看注释一眼看去以为AQS是使用的CLH队列，单向链表实现的同步队列。

再看代码实现，每个Node实例节点却是维护了前后节点的指针，也就是双向链表结构。

那么问题来了，按理说CLH这种单向的链表结构应该够用了（入队、出队、锁获取与释放），那为什么还需要多此一举？

重新仔细阅读注释：

结合注释我们发现，prev和next指针主要是中断和唤醒后续阻塞线程时需要用到，这也就是为什么用双向链表的原因，也就是本文的答案。

作用之一，用于中断

用于在AQS#acquireInterruptibly(int arg)获取锁的过程中处理中断信号。

我们知道，相比于线程获取synchronized锁的过程中不能被中断，基于AQS实现的ReentrantLock是在获取锁的过程中是可被中断的。

下面看一个API，acquireSharedInterruptibly尝试获取共享锁（可中断）：

可以看到，在获取锁成功后，退出for自旋。并且每次当前节点的前一个节点状态为SIGNAL时，随之都伴随着一次中断信号的检测。保证在获取锁之前检测中断信号到能抛出中断一次。
当中断异常发生后，将放弃获取锁，转而在finally中通过cancelAcquire从等待队列中删除当前线程封装的Node节点。

parkAndCheckInterrupt()负责检测阻塞获取锁过程中的中断信号。

cancelAcquire(Node node)负责将被中断的线程节点从AQS同步队列中移除。

综上，中断操作需要在 AQS 同步队列中删除线程 Node，这也就转化为在链表中删除节点的问题。如果想从CLH 单向链表中间删除一个 Node，因为只维护了前一个节点的指针，想要知道后一个节点的指针的话，不通过从tail开始使用快慢指针遍历是无法办到的。因此直接维护prev、next指针，以降低删除操作的复杂性。

作用之二，用于唤醒

我们知道，CLH是单向的，维护前一个节点指针，后继线程轮询前一个节点的状态，从而判断是否可以获取锁。

而当多线程竞争时，CLH的轮询是非常耗费性能的，无论是对CPU还是总线来说，都是一种巨大的压力。

AQS对CLH进行了改进，后继获取锁的线程在经过有限次的轮询后，依旧获取不到锁将陷入阻塞。优点：减少轮询无效操作；缺点：后继线程Node在阻塞后无法感知前一个线程Node的状态，锁被释放时将无法主动醒来。

于是AQS使用了双指针，在CLH的prev基础上增加了next。AQS维护了next指针，以便活跃线程释放锁后主动唤醒后续阻塞线程去竞争锁。

我们直接上代码，对以上论述进行验证：