aqs中等待队列头结点必须为虚节点，以解耦入队与唤醒逻辑、避免竞争条件和状态歧义；其通过惰性初始化、cas稳定维护，并确保唤醒始终从head.next开始。
AQS 中的等待队列头结点设计为虚节点（dummy head），核心目的是**解耦入队逻辑与唤醒逻辑，避免竞争条件和状态判断歧义**。这个看似“无用”的节点，实则是线程安全、无锁操作的关键支点。
为什么头结点必须是虚节点？
真实等待的线程从第二个节点（即 head.next）开始，head 本身不关联任何线程或同步状态。这样设计有三个关键好处：
- 避免唤醒时重复检查 head 是否为空：如果 head 直接指向首个等待线程，那么当该线程被唤醒并出队后，head 就变成 null 或需重新赋值，极易在并发修改中丢失更新；设为虚节点后，head 始终存在且稳定，唤醒逻辑只需关注 head.next
- 统一首次入队流程：无论队列空或非空，新节点总是在 tail 后插入，然后通过 CAS 修改 tail；若 head 不是虚节点，首次入队就要同时初始化 head 和 tail，增加 CAS 失败概率和逻辑分支
- 支持“自旋 + 阻塞”前的安全状态快照：线程在阻塞前会检查前驱是否为 head（即自己是否是队首），这个判断依赖 head 的稳定性。虚 head 确保了“我排第一”这一语义始终可被原子判断
虚节点如何被创建和维护？
虚 head 在队列首次有线程入队时惰性创建，由第一个入队线程完成初始化：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 当队列为空（tail == null），当前线程先尝试 CAS 设置 tail 为自身节点；若成功，再 CAS 设置 head 为同一节点——但此时它还不是虚节点
- 紧接着，第二个线程入队时发现 tail != null，于是将自己插入 tail 后，并 CAS 更新 tail；此时原 head 节点（即第一个线程节点）被后续线程视作“实际等待者”，而代码逻辑会立即用一个新节点替换掉它作为 head，使其退化为虚节点
- 真正稳定的虚 head 是在
enq()方法中通过“死循环 + CAS”确保的：若 tail 为空，就先新建一个 Node（new Node()，无 thread、无 waitStatus），再 CAS 设为 head 和 tail；这个新建节点就是标准虚节点
唤醒时如何安全跳过虚 head？
唤醒操作（如 unparkSuccessor(h)）总是从 head.next 开始，但需小心处理几种边界：
- head.next 为 null：说明队列刚初始化或正被并发修改，直接返回，不唤醒
- head.next 已取消（waitStatus == CANCELLED）：从 head.next 开始向后遍历，跳过所有取消节点，找到第一个有效后继；找不到则唤醒整个队列（极少见）
-
唤醒后需重置 head：被唤醒线程获得锁后，在
setHead()中将自己的节点设为新 head，并显式置空其 thread 字段（表示已出队），原 head（虚节点）自然被 GC；新 head 仍是虚节点，因为它的 thread 也被清空了
虚节点带来的副作用与应对
虚节点虽提升安全性，但也引入两个常见困惑：
- dump 线程栈时看到 head.thread == null：这是正常现象，不代表 bug；AQS 的 Javadoc 明确说明 head 仅用于引导，不承载业务线程
-
遍历队列时容易漏掉首个真实等待者：调试或监控时应从
head.next开始遍历，且跳过 waitStatus == CANCELLED 的节点；JDK9+ 的getQueuedThreads()内部正是这样做的
虚节点不是冗余设计，而是 AQS 实现“无锁+公平+可取消”等待语义的基石。它让入队、出队、唤醒三类操作彼此隔离，各只关心局部状态，最终支撑起 ReentrantLock、Semaphore、CountDownLatch 等组件的稳健运行。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
