AQS同步队列本质是基于CLH思想的虚拟FIFO双向链表，用于线程排队与唤醒；它由volatile head/tail指向Node节点，节点含thread、prev/next和waitStatus，入队后线程park阻塞，释放时唤醒head.next节点。
AQS 的同步队列本质是一个基于 CLH 思想变体的 FIFO 双向链表，它不负责业务逻辑，只管“排队”和“唤醒”。理解它，关键不是背结构，而是看清线程怎么进来、怎么停、怎么被叫醒。
同步队列不是真实队列，而是虚拟双向链表
AQS 的队列头（head）和尾（tail）都是 volatile Node 引用，初始为 null。第一个争抢失败的线程会触发队列初始化：先创建一个空的哨兵节点作为 head，再把当前线程封装成新节点，通过 CAS 原子操作插入到 tail 后面。这个过程保证了多线程安全入队。
- 每个 Node 包含：thread（关联线程）、prev/next（前后指针）、waitStatus（状态标识，如 SIGNAL 表示后继可被唤醒）
- head 节点永远是“已获取资源”的线程（或虚节点），真正等待的是从 head.next 开始的节点
- tail 永远指向最后一个入队节点，所有新节点都追加到 tail 后，然后更新 tail 指针
节点入队后立即挂起，靠 LockSupport.park() 实现
线程在 tryAcquire 失败后，并不会轮询等待，而是走标准流程：构造 Node → 入队 → 设置前驱节点的 waitStatus 为 SIGNAL → 调用 LockSupport.park() 进入阻塞态。此时线程让出 CPU，不消耗资源。
- 挂起前会检查一次：如果前驱节点是 head，说明自己可能是下一个获锁者，会再尝试一次 tryAcquire，避免过早阻塞
- 挂起后线程处于 WAITING 状态，JVM 层面由本地方法 park() 控制，与 Object.wait() 不同，它不依赖 synchronized
- 被唤醒不等于获得锁，只是重新参与竞争——唤醒后仍要调用 tryAcquire 再判断 state 是否可用
FIFO 的公平性体现在“谁先到谁先得”，但非公平锁会绕过队列
公平锁模式下，每次 acquire 都先检查队列是否为空且当前线程是否排在 head 后面；只要队列非空，就强制入队，不给插队机会。而非公平锁在 acquire 时会先直接 CAS 尝试抢锁，失败才入队——这就是“插队”的来源。
立即学习“Java免费学习笔记（深入）”；
- ReentrantLock 默认是非公平的，所以即使有线程在队列里等着，新来的线程也可能抢先拿到锁
- 队列本身不干预抢锁行为，它只忠实地记录“谁在等、谁在前、谁在后”，调度权交给上层实现
- state 的 CAS 修改 + waitStatus 的状态流转 + park/unpark 的配合，共同构成原子协作链条
不复杂但容易忽略：AQS 队列不是用来“计时”或“优先级排序”的，它只做一件事——按到达顺序组织等待者，并在资源释放时精准唤醒最前面那个。
