ReentrantLock公平锁详解：hasQueuedPredecessors解析

本文深入剖析了ReentrantLock公平锁的核心机制——hasQueuedPredecessors方法，揭示其如何通过仅检查head和head.next两个节点的精巧设计，以最小开销严格保障“先到先得”的公平性；同时澄清了该方法常被误用的典型场景（如混淆队列非空判断、错误用于非公平逻辑或重入检测），对比了非公平锁跳过此检查所带来的性能优势与公平性取舍，并给出了实战调试要点：必须确认显式启用公平模式、验证真实排队状态、并在争抢发生时观察节点位置，强调这一逻辑只在真正存在线程竞争排队时才激活生效。

为什么 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 —— 它只在真有“争”时才起作用。

本篇关于《ReentrantLock公平锁详解：hasQueuedPredecessors解析》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！