同步队列是基于clh变体的双向链表而非真实queue；线程先尝试获取锁，失败后才入队并可能被park；唤醒仅针对有效后继节点，且需state+node+park/unpark严格配合。

同步队列不是真实队列，而是 CLH 节点链表

AQS 的「同步队列」没有 java.util.Queue 实例，它是一个由 Node 构成的双向链表，每个 Node 封装一个线程、等待状态（waitStatus）、前驱和后继指针。这个结构叫 CLH（Craig-Landin-Hagersten）变体，本质是虚拟队列——只靠节点间引用维系顺序，不依赖容器对象。

常见误解是以为调用 acquire() 后线程立刻被「加入队列并阻塞」。实际流程是：

• 先尝试 tryAcquire(int arg)，失败才走入队逻辑
• addWaiter(Node.EXCLUSIVE) 用 CAS 循环将新 Node 拼到队尾，失败则重试
• 只有成功入队后，才在 acquireQueued(Node, int) 中判断：若前驱是头节点，再次尝试获取；否则调用 LockSupport.park(this) 阻塞自己

也就是说，阻塞动作发生在入队完成之后，且仅当该线程不具备「立即竞争资格」时才发生。

唤醒不是广播，而是精准 unpark 前驱节点的后继

释放锁时，release(int arg) 调用 tryRelease(int arg) 成功后，会执行 unparkSuccessor(Node node) —— 注意它唤醒的不是「队头线程」，而是当前节点（即刚释放锁的节点）的后继节点。

这个设计很关键，因为：

• 头节点（head）本身不关联任何线程，它只是个哨兵；真正等待的是头节点的 next
• unparkSuccessor 会跳过已取消（waitStatus == Node.CANCELLED）的后继，找第一个有效的节点唤醒
• 被唤醒的线程回到 acquireQueued 自旋中，重新尝试 tryAcquire，而不是直接获得锁

所以「唤醒」不等于「获得锁」，只是给了它一次重新竞争的机会。这也是为什么 AQS 不会出现惊群效应，也不会误唤醒无关线程。

state 变量和 park/unpark 是阻塞唤醒的底层支撑

整个机制能成立，依赖两个不可替代的底层能力：

• state 是 volatile int，所有对它的读写都具备可见性与有序性；compareAndSetState 提供原子更新，这是判断能否获取/释放资源的唯一依据
• LockSupport.park() 和 LockSupport.unpark(Thread) 是 JVM 层面的线程阻塞/唤醒原语，它们不依赖 synchronized，也不进入 Object Monitor，开销远低于 wait/notify

如果你在自定义同步器里漏掉 compareAndSetState 的正确使用，或者误用 Object.wait() 替代 park()，同步队列就会失效：要么多个线程同时闯入临界区，要么线程永远无法被唤醒。

调试时最该盯住的三个地方

当你发现线程卡死或唤醒异常，不要直接翻源码，先确认这三点：

• 是否在 tryAcquire 或 tryRelease 中修改了 state，但没返回正确的布尔值（比如该返回 true 却返回 false）
• 是否在 acquireQueued 的循环中忽略了中断检查，导致线程被中断后仍继续 park（应配合 Thread.interrupted() 处理）
• 是否在 unparkSuccessor 前，手动修改了 head 或 tail 指针（AQS 内部通过 CAS 维护，外部不应干预）

同步队列的「先进先出」是逻辑保证，不是物理顺序；它的可靠性完全建立在 state 状态机 + Node 链表 + park/unpark 这三者的严格配合上。少一个环节，就不是 AQS，而是一段不可预测的并发代码。