FairSync的tryAcquire通过调用hasQueuedPredecessors()体现“先来先服务”：若队列非空且头节点后继不是当前线程，则直接返回false，强制入队，杜绝插队，从加锁入口就保障公平性。
FairSync 的 tryAcquire 怎么体现“先来先服务”
公平锁的核心不是“不插队”，而是「在尝试获取锁前，先检查队列里有没有更早等待的线程」。FairSync 的 tryAcquire 会调用 hasQueuedPredecessors() —— 这个方法才是公平性的关键判据。
它返回 true 的条件是：AQS 等待队列非空，且 head.next 对应的节点（即真正排队等锁的第一个线程）不是当前线程。只要队列里有人排在前面，哪怕 state == 0，tryAcquire 也直接返回 false，强制当前线程进队，而不是像 NonfairSync 那样 CAS 抢一次再说。
所以公平性不是靠唤醒顺序保证的，而是靠「获取阶段就拒绝插队」实现的。这点容易误解：很多人以为 FairSync 是唤醒时才排序，其实排队逻辑在加锁入口就卡死了。
unparkSuccessor 为什么从 tail 往前找有效后继
unparkSuccessor 在释放锁时被调用，目标是唤醒「队列中下一个该抢锁的线程」。但它不简单取 node.next，而是：
- 先检查
node.next是否存在且waitStatus （即不是已取消的节点） - 如果不符合，就从
tail开始向前遍历，找离node最近的一个有效节点
这是因为 AQS 队列的入队操作是「先连 prev，再连 next」，存在短暂窗口：新节点已设置 prev 指向 tail，但还没来得及更新 tail 的 next。此时从 tail 往前扫，能避开这个竞态，确保找到真正可唤醒的节点。
这个设计和 FairSync 无关，是 AQS 通用机制，但对理解公平锁的唤醒可靠性很重要——它不依赖 next 字段的绝对正确性，而是用更健壮的反向扫描兜底。
为什么 FairSync 的 acquireQueued 里要 selfInterrupt
当线程在队列中等待时，可能被中断（Thread.interrupt()）。FairSync 的 acquireQueued 在检测到中断状态后，会调用 selfInterrupt()（即 Thread.currentThread().interrupt()）。
AI 舌诊面诊问诊医疗系统 + 诊疗商城系统源码是一套结合 AI 辅助诊断与商品转化的健康类程序，基于浩创云、ThinkPHP（PHP）开发，支持微信服务号与 H5 端，适合做中医舌诊面诊问答、健康建议推送以及配套诊疗商品的运营。
这不是多此一举，原因有二：
- 线程在
park时被中断，JVM 会清除中断状态，只抛InterruptedException；但 AQS 中线程是通过LockSupport.park()阻塞的，它不会抛异常，只会让Thread.interrupted()返回true，然后继续循环 -
selfInterrupt()是把中断“还回去”，让上层调用者（比如lockInterruptibly()）能感知并处理中断，而不是静默吞掉
这点在公平锁场景下尤其关键：一个被中断的线程如果默默继续排队，就破坏了“响应中断”的契约。而 selfInterrupt() 是保障这一语义的最小必要动作。
state == 0 时 unparkSuccessor 还会执行吗
会，而且必须执行。常见误区是认为「只有释放锁成功（state 变为 0）才唤醒」，但 unparkSuccessor 是在 tryRelease 返回 true 后立即调用的，而 tryRelease 返回 true 的唯一条件就是 state == 0。
换句话说：只有完全释放（state 归零）才会触发唤醒。这正是可重入锁的设计约束——如果一个线程持有锁 3 次，前两次 unlock() 调用 tryRelease 都返回 false，不会唤醒任何人；只有第三次归零，才唤醒队首。
这个细节决定了公平锁的唤醒时机非常确定：不是“每次 unlock 都唤醒”，而是“彻底释放后，唤醒下一个排队者”。漏掉这一点，就容易误以为公平锁唤醒是逐次进行的。
