节点自旋时判断前驱是否为头节点（p == head）是获取锁的关键条件，成立则说明当前节点是队列中首个有资格尝试获取锁的节点；head为虚拟节点，thread为null，仅作结构锚点，真正持锁信息由state和exclusiveownerthread维护。
在 AQS 中，节点自旋时判断前驱节点是否为头结点，是决定能否尝试获取锁的关键一步。这个判断发生在 acquireQueued 方法的主循环里，逻辑直接、高效，不依赖额外状态查询。
核心判断逻辑：p == head
每次循环开始时，当前节点会调用 node.predecessor() 获取前驱节点 p，然后直接比较：if (p == head)。这里的 == 是引用相等判断，不是值或内容比较。
这个判断成立，说明当前节点是同步队列中排在最前面的等待者（即 head 的直接后继），具备“轮到它抢锁”的资格。此时才调用 tryAcquire(arg) 尝试获取同步状态。
为什么 head 本身不存有效线程？
AQS 的 head 是一个**虚拟头节点（dummy node）**，初始化于 enq 或首次入队时，它的 thread 字段为 null，仅作占位和链表结构锚点使用。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
所以即使 p == head 成立，也不代表 head 在“持有锁”，而是表明：当前节点是队列中第一个有资格竞争的线程节点。真正持有锁的线程信息，由 state 和 exclusiveOwnerThread（如 ReentrantLock 中）维护，与 head 节点无关。
实际执行中的几个关键点
-
head 是懒加载的：队列为空时没有 head；首个线程入队失败后触发
enq，才会创建 head 并指向它 -
head 可能被更新多次：每次有节点成功获取锁，就会调用
setHead(node)，把当前节点设为新 head，原 head 被断开并帮助 GC -
前驱为 head 不保证一定能抢到锁：只是获得一次
tryAcquire的机会；若失败，仍需继续走挂起流程（进入shouldParkAfterFailedAcquire） -
不会出现 p 为 null：因为
addWaiter已确保每个新节点都有合法前驱（哪怕刚初始化时连上 head），predecessor()内部有空检查并抛异常
和公平性策略的关系
该判断机制本身是中立的，但它的触发时机受锁类型影响：
-
公平锁：线程必须严格排队，入队后只在
p == head时才允许tryAcquire，不给插队机会 -
非公平锁：线程会先直接调用
tryAcquire（可能抢到刚释放的锁），失败后再入队；入队后同样遵守p == head才重试，保障队列内顺序
本质上，p == head 是 AQS 实现 FIFO 等待语义的最小原子判断，轻量、确定、无锁，构成了整个同步队列调度的基础。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
