acquire先调用tryacquire是因采用“乐观优先”策略：线程先非阻塞尝试获取资源（如cas修改state），成功则直接返回，避免无谓入队；仅当tryacquire返回false（资源被占用）才执行addwaiter和acquirequeued。

acquire 方法为什么先调用 tryAcquire 而不直接入队

因为 acquire 的设计是「乐观优先」：线程会先尝试一次非阻塞获取（比如 CAS 修改 state），成功就跳过排队，避免无谓的节点创建和队列操作。只有 tryAcquire 返回 false，才说明资源已被占用，此时才走排队流程。

这个判断非常关键——它决定了是否触发后续的 addWaiter 和 acquireQueued。如果子类实现的 tryAcquire 逻辑有误（比如始终返回 false），线程就会无意义地反复入队、阻塞、唤醒，造成 CPU 空转或死锁倾向。

• tryAcquire 是模板方法，必须由子类重写；AQS 自身抛 UnsupportedOperationException
• ReentrantLock 的公平/非公平版本，tryAcquire 行为完全不同：非公平版允许插队，公平版会检查 hasQueuedPredecessors()
• 注意：acquire 不响应中断，而 acquireInterruptibly 才会在等待中检查中断状态

addWaiter 如何把线程安全地塞进队尾

addWaiter 并不是简单地追加节点，而是分两步尝试：先用 CAS 快速插入（利用当前 tail），失败则 fallback 到 enq 的死循环重试。这背后是为了应对多线程并发修改 tail 的竞争场景。

常见误区是认为「队尾插入」天然线程安全——其实不然。tail 是普通 volatile 字段，没有原子性保障，所以必须靠 CAS + 循环兜底。

• 第一次尝试：node.prev = pred 后，再 compareAndSetTail(pred, node)；若失败，说明 tail 已被其他线程更新
• enq 中的初始化逻辑很重要：当 tail == null 时，先 compareAndSetHead(new Node())，再设 tail = head，确保头尾一致
• 节点的 prev 指针设为 volatile，但 next 不是——所以遍历队列只能从 tail 往前找 prev，不能依赖 next

acquireQueued 怎么决定是否 park 当前线程

acquireQueued 是真正的「排队+阻塞」核心。它不会一进来就 park，而是每次循环都检查自己是不是队首的下一个节点（即 p == head），只有这时才再次调用 tryAcquire 尝试抢锁。抢不到，才进入阻塞准备阶段。

是否 park 由 shouldParkAfterFailedAcquire(p, node) 决定，它会检查前驱节点的 waitStatus：只有前驱是 SIGNAL(-1) 才放心 park；否则先把它设成 SIGNAL，下一轮再试。

• park 前必须确保前驱节点已准备好唤醒自己，否则可能永久挂起（lost wakeup）
• parkAndCheckInterrupt() 返回的是「park 期间是否被中断」，但不抛异常，只是记录标记，最终在 finally 块里统一处理
• 如果 acquireQueued 返回 true，说明线程在等待中被中断过，上层 acquire 会调用 selfInterrupt() 补回中断状态

为什么释放锁时总是 unpark head.next 而不是 tail

因为 AQS 队列是 FIFO，只有队首节点（head.next）才有资格竞争资源。释放锁后调用 unparkSuccessor，目标永远是 head.next，哪怕它已被取消（waitStatus == CANCELLED），也会向后遍历找第一个有效的节点。

这里容易忽略的关键点是：head 本身是个哑节点（dummy node），不关联任何线程；真正等待的线程在 head.next。所以唤醒逻辑必须从 head 出发，而不是从 tail 或任意位置开始扫描。

• head 在 setHead(node) 时才被更新，且只在 tryAcquire 成功后执行，保证了语义正确性
• 如果 head.next 为 null 或已取消，unparkSuccessor 会从 tail 往前遍历 —— 这是兜底策略，但非常规路径
• 不要假设 tail 就是最后一个有效等待者；它可能指向一个刚入队但还没来得及设置 prev 的节点