为什么aqs采用的是双向链表的设计

AQS为什么要使用双向链表面试

AQS采用双向链表设计的主要原因在于其高效性：双向链表便于快速插入/删除节点（如线程中断时移除节点），能直接访问前驱节点判断线程状态，减少头部竞争，支持条件队列高效迁移，以及从尾部遍历快速定位线程。这些特性使双向链表成为AQS实现高并发同步机制的最佳选择，有效提升了线程管理和同步操作的效率。

AQS为什么用双向链表？

看注释一眼看去以为AQS是使用的CLH队列，单向链表实现的同步队列。 再看代码实现，每个Node实例节点却是维护了前后节点的指针，也就是双向链表结构。 那么问题来了，按理说CLH这种单向的链表结构应该够用了（入队、出队、唤醒），那为什么还需要多此一举？ 重新仔细阅读注释： 结合注释我们发现，prev和next指针主要是中断和唤醒后续阻塞线程时需要用到，这也就是为什么用双向链表的原因，也就是本文的答案。 中断 用于在AQS#acquireInterruptibly(int arg)获取锁的过程中处理中断.

关于这个问题，99%的人都回答不上来。而且我简单翻了一些技术博客，基本上全都是错的。对AQS理解不深刻的情况下，乱回答，导致很多同学被误解。理解一个技术为什么这么设计，关键在于它需要解决什么样的问题。另外，我将所有Java面试系列制作成了完整的面试文档。它的便捷之处在于，可以通过检索的方式，找到你想要的面试题，目前已经更新180期，总计超过15W字！...

juc

解答：首先，单向链表的尾部节点只会记录下一个节点的位置，而不会记录上一个节点的，因此单向链表只会从一个方向查找，双向链表的节点会同时前驱和后继节点，因此无论从哪一个方向查找都可以，对于某些需要双向检索的同步操作和线程调度非常有用。其次：后继节点，需要判断前驱节点的锁的状态，来判断本身节点是否需要继续阻塞等待，单向链表满足不了，因为找不到上一个节点，当然也无法判断。AQS的底层就是采用双向链表，主要包括管理线程队列、快速的插入和删除、动态管理线程的状态、避免线程的阻塞和唤醒的开销。

AQS（AbstractQueuedSynchronizer）使用双向链表的主要原因是为了实现等待队列（Wait Queue）。这个等待队列是用于管理在同步器上等待的线程，例如在获取锁时发现锁被占用，线程就会加入到等待队列中等待。使用双向链表作为等待队列的底层数据结构，是为了提供高效的队列操作，保持线程等待的有序性，同时支持在节点之间传播状态信息，从而实现了 AQS 的核心同步机制。这种设计使得 AQS 能够灵活地支持各种同步器的实现。

所以，（如图）为了避免这个问题，加入到链表中的节点在尝试竞争锁之前，需要判断前置节点是不是头节点，如果不是头节点，就没必要再去触发锁竞争的动作。所以这里会涉及到前置节点的查找，如果是单向链表，那么这个功能的实现会非常复杂。第一个方面，没有竞争到锁的线程加入到阻塞队列，并且阻塞等待的前提是，当前线程所在节点的前置节点是正常状态，这样设计是为了避免链表中存在异常线程导致无法唤醒后续线程的问题（如图）所以线程阻塞之前需要判断前置节点的状态，如果没有指针指向前置节点，就需要从 head 节点开始遍历，性能非常低。

这个问题乍一看有点抽象，甚至有点学术，但作为一个程序员，我觉得这背后其实有很多值得聊的内容。说实话，这个问题让我想起了刚刚开始接触并发编程时，自己的那些个疑惑——为什么要设计得那么复杂？双向链表到底有什么优势呢？好吧，我知道你们一定也跟我有一样的想法：不是直接使用链表就行了吗？非得双向链表有什么不一样吗？其实，AQS底层的实现是依赖于双向链表来管理线程的，它的设计其实有很深的内涵，下面就让我带你一起来好好分析一番。

AQS：AbstructQueuedSynchronizd(抽象队列同步器)，出现在 JDK 1.5 中。他是很多同步器的基础框架，比如 ReentrantLock、CountDownLatch 和 Semaphore 等都是基于 AQS 实现的。AQS内部，维护了一个FIFO队列和一个volatile的int类型的state变量。在state=1的时候表示当前对象锁已经被占有了，state变量的值修改的动作通过CAS来完成。

一位工作4年的程序员，简历上写了精通并发编程，并且还阅读过AQS（AbstractQueuedSynchronizer）的源码，然后面试官只问了这样一个问题“AQS为什么要采用双向链表结构”？，然后就垮了！其实AQS大家都不陌生，它是J.U.C包里面一个非常重要的线程同步器。今天，我给大家聊聊我的理解。...

双向链表支持双向遍历，插入和删除更加灵活。

首先，双向链表有两个指针，一个指针指向前置节点，一个指针指向后继节点。所以，双向链表可以支持常量 O(1) 时间复杂度的情况下找到前驱节点。因此。