CLH队列锁：AQS如何用链表管理竞争节点

AQS底层采用基于CLH思想深度优化的虚拟双向链表来管理锁竞争节点，它摒弃了传统队列容器，仅通过Node间的prev/next指针构建轻量、无扩容开销、天然支持并发的逻辑队列；这种“虚拟”设计不仅大幅降低内存占用和同步成本，还赋予链表取消节点、精准唤醒与头节点复用等关键能力，再配合volatile state变量作为资源状态核心裁判，以及park/unpark构成的高效叫号机制，三者协同实现了高并发下可中断、可追溯、强可控的有序资源调度——正是这一精巧结构，成为Java并发包高性能锁实现的底层基石。

AQS 底层用的不是传统意义上的“队列”，而是一个基于 CLH 思想改造的虚拟双向链表，它不依赖 Queue 实例，而是靠 Node 节点之间的前后指针维系逻辑顺序。这个结构既轻量又灵活，是 Java 并发包能高效处理锁竞争的关键设计。

CLH 队列在 AQS 中为什么是“虚拟”的？

所谓“虚拟”，是指 AQS 并没有定义一个独立的 Queue 类或数组容器来存节点；所有排队线程都被封装成 Node 实例，通过 prev 和 next 两个引用构成双向连接。头尾节点靠 CAS 原子操作动态维护，整个结构只存在于节点间的指针关系中——内存开销小、无扩容成本、天然支持并发修改。

• Node 不持有“队列长度”或“容量”等冗余字段，每个节点只关心自己和相邻节点
• 入队时只更新尾节点的 next 和新节点的 prev，无需全局锁或重排
• 出队或取消节点时，仅需调整前后指针，不涉及数组移动或对象拷贝

双向链表比原始 CLH 单向链表强在哪？

原始 CLH 是单向自旋队列，适合短时等待；AQS 改造成双向链表后，支撑了更通用的阻塞式同步语义：

• 支持节点取消：线程被中断或超时，可安全断开自身与队列的连接（设置 waitStatus = CANCELLED），前驱节点能通过 next 指针跳过它
• 唤醒更精准：释放锁时，只需 unpark 后继节点；但若后继已取消，可通过 next 找到下一个有效节点，避免唤醒失败
• 头节点可复用：AQS 设置了虚拟头节点（head 指向一个空 Node），让入队/出队逻辑统一，不用频繁判空或特殊处理首节点

state 变量和节点如何协同应对竞争？

volatile int state 是资源状态的唯一权威标识，所有竞争都围绕它展开：

• 线程调用 tryAcquire() 时，用 CAS 尝试将 state 从 0 改为 1（或递增）；成功即获得资源，不入队
• 失败则进入 acquire() 流程：新建 Node → CAS 入队尾部 → 调用 LockSupport.park() 阻塞自己
• 当持有锁的线程 release() 时，先更新 state，再 unpark 成功唤醒 head.next 对应的线程，后者重新尝试 CAS 获取 state

整个过程里，state 是“裁判”，节点链表是“候场名单”，park/unpark 是“叫号机制”——三者配合，把高并发下的资源争抢变成了可预测、可中断、可追溯的有序调度。

到这里，我们也就讲完了《CLH队列锁：AQS如何用链表管理竞争节点》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！