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的节点
