ReentrantLockFairSync源码解析：AQS唤醒机制详解

本文深入剖析了ReentrantLock中FairSync公平锁的底层实现机制，重点揭示了其“先来先服务”原则并非依赖唤醒时的排序，而是通过在加锁入口处严格拦截——即tryAcquire调用hasQueuedPredecessors()主动检查队列中是否存在更早等待的线程，一旦发现有人排队在前，立即拒绝获取并强制入队，从根源上杜绝插队；同时澄清了unparkSuccessor为何需从tail向前遍历寻找有效后继，而非简单取node.next，从而帮助读者穿透AQS表层逻辑，真正理解公平锁“公平性”的本质所在。

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()）。

这不是多此一举，原因有二：

• 线程在 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 都唤醒”，而是“彻底释放后，唤醒下一个排队者”。漏掉这一点，就容易误以为公平锁唤醒是逐次进行的。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~