AQS中的CLH同步队列是基于Node的虚拟双向链表，非传统Queue；它通过CAS入队、waitStatus控制阻塞、双向指针支持取消与精准唤醒，实现高效线程调度。
AQS 中的 CLH 同步队列不是传统意义上的 Queue，而是一个由 Node 节点构成的虚拟双向链表。它的核心作用是协调线程在竞争资源失败后的排队、阻塞与唤醒过程，Node 就是这个机制中承上启下的关键载体。
Node 是如何被创建和入队的
当线程调用 acquire() 尝试获取锁失败后，并不会立刻阻塞，而是先封装为一个 Node：
- Node 通过 addWaiter(Node.EXCLUSIVE) 创建并尝试以 CAS 方式插入队尾；插入失败会重试，确保线程安全
- 新节点的 prev 指向前驱（当前 tail），next 指向 null；插入成功后更新 tail 指针指向该节点
- 此时 Node 的 thread 字段保存当前线程引用，waitStatus 初始化为 0（表示正常等待）
Node 的 waitStatus 状态如何影响阻塞逻辑
waitStatus 不是装饰字段，而是决定线程是否该 park 的直接依据：
- SIGNAL (-1)：表示“我的后继节点需要被唤醒”，通常由前驱节点在释放锁或准备阻塞时设置
- CANCELLED (1)：线程超时、中断或放弃竞争，该 Node 不再参与调度，后续会被跳过或清理
- CONDITION (-2)：仅用于 Condition 队列，不在同步队列中生效
- 在 shouldParkAfterFailedAcquire() 中，若前驱 waitStatus 为 SIGNAL，则返回 true 允许 park；否则尝试将其设为 SIGNAL 并重试
唤醒时 Node 如何被精准定位和激活
唤醒不是广播，而是基于节点关系的定向通知：
立即学习“Java免费学习笔记（深入）”；
- 释放锁后，unparkSuccessor(head) 从 head 开始向后扫描第一个 waitStatus ≤ 0 的有效后继节点
- 跳过所有 CANCELLED 节点，避免无效 unpark；找到后调用 LockSupport.unpark(node.thread)
- 被唤醒的线程回到 acquireQueued() 自旋中，再次调用 tryAcquire() 竞争 state，而不是直接获得锁
- 成功获取后，该 Node 成为新的 head（哨兵节点），其 thread 字段置 null，prev/next 断开，原 head 可被 GC
Node 的双向链表结构为何不可替代
相比原始 CLH 单向自旋锁，AQS 改为双向链表解决了实际工程中的关键问题：
- 支持取消操作：线程中断或超时时，可通过 prev 快速定位前驱并修正其 next 指针，实现 O(1) 删除
- 便于唤醒传播：共享模式下需唤醒多个后继，双向结构允许从 tail 往前遍历或跳过无效节点
- 避免“假唤醒”风险：每个 Node 显式持有 thread 和 waitStatus，状态可验证，不依赖隐式轮询
- head 始终是哨兵，真正执行的是 head.next；这种设计分离了队列管理和业务线程，提升稳定性
