hasqueuedpredecessors 是公平锁的关键判据，因其在 tryacquire 中严格检查当前线程是否队列最前：仅通过 head 和 head.next 判断有无前置等待者，返回 false 才允许 cas 抢锁，精准保障先到先得。
为什么 hasQueuedPredecessors 是公平锁的关键判据
公平锁不是靠“排队喊号”实现的，而是靠每次加锁前严格检查：当前线程是否真正在队列最前面等待。而 hasQueuedPredecessors 就是这个检查动作的唯一出口——它返回 true，说明有别的线程比你更早排队，你必须让出；返回 false，才允许尝试 CAS 抢锁。
这个方法不查整个队列，只看两个节点：head 和 head.next。因为公平性只取决于“有没有人排在你前面”，而不是“后面还有多少人”。
- 如果队列为空（
head == tail），直接返回false—— 没人排队，你就是第一个 - 如果
head.next为null，说明初始化未完成或刚入队，也返回false（避免空指针 + 保证安全偏移） - 否则，只要
head.next对应的线程不是当前线程自己，就返回true—— 有人在你前面等着
hasQueuedPredecessors 的典型误用场景
很多人把它当成“队列是否非空”的判断，结果在非公平锁逻辑里误加调用，导致吞掉本该抢锁的机会。它只服务于公平策略，且只在 tryAcquire 入口被 ReentrantLock.FairSync 调用，绝不该手动触发。
- 在自定义同步器中照搬此逻辑但没同步
head读取顺序 → 可能读到过期值，漏判前置节点 - 拿它替代
isHeldByCurrentThread()判断重入 → 完全无关，hasQueuedPredecessors不关心持有状态，只看队列位置 - 在
unlock()或条件队列操作中调用 → 无意义，释放锁不依赖排队顺序
对比非公平锁：nonfairTryAcquire 为什么跳过它
非公平锁的 nonfairTryAcquire 根本不查队列，上来就 CAS 尝试修改 state。只有失败后，才进 AQS 的通用入队流程（acquireQueued）。这意味着：刚释放的锁可能被一个新来的线程立刻抢走，哪怕队列里已有等待者。
这种设计牺牲公平性换吞吐——尤其在低竞争时，省去队列检查和节点创建开销。
- 公平锁多一次 volatile 读（
head、head.next）+ 引用比较，高并发下可能成为微小瓶颈 - 非公平锁在 Linux 上更贴合 futex 唤醒机制，唤醒延迟更低
- 注意：
ReentrantLock默认是非公平的，传true构造才启用公平模式，这点常被忽略
调试时怎么看 hasQueuedPredecessors 是否生效
不能只看源码，得结合线程堆栈和队列状态验证。当怀疑公平性失效，优先检查三件事：
- 确认构造时传了
true：new ReentrantLock(true)，而非默认无参构造 - 用
getQueueLength()和hasQueuedThreads()确认队列确实有等待者 - 在
tryAcquire断点处观察：当前线程是否出现在head.next对应的Node中（可通过node.thread == Thread.currentThread()验证）
最容易被忽略的是：即使启用了公平锁，如果所有线程都快速获取并释放，根本不会形成有效排队，hasQueuedPredecessors 始终返回 false —— 它只在真有“争”时才起作用。
