公平锁通过hasQueuedPredecessors()检查队列中是否存在更早等待的线程：若head≠tail且head.next非空且不指向当前线程，则返回true强制排队；仅当无前驱时才尝试CAS抢锁，以此保障FIFO顺序。

ReentrantLock 的公平锁通过 hasQueuedPredecessors() 判断当前线程是否该“插队”——本质上是检查 AQS 队列中是否存在等待时间更长的线程。

公平锁的核心逻辑：谁先排队，谁先获取

公平锁要求线程按进入同步队列的顺序获取锁。它在尝试获取锁（tryAcquire）时，不是直接抢锁，而是先调用 hasQueuedPredecessors() 做准入检查：如果返回 true，说明有前驱节点（即已有线程在排队且比当前线程更早），当前线程必须排队；只有返回 false 时，才尝试 CAS 抢占锁。

hasQueuedPredecessors() 怎么判断“有没有前辈”

这个方法只做两件事：

• 检查 AQS 的 head 是否等于 tail：相等说明队列为空（没人在排队），返回 false
• 否则，取 head.next，判断它是否为 null 或是否指向当前线程：
  – 如果 head.next == null，说明节点刚入队、尚未完成初始化（可能正执行 enq() 中的 CAS），保守起见视为有前驱，返回 true
  – 如果 head.next != null 且 head.next.thread != Thread.currentThread()，说明队首后确实有别的线程，返回 true
  – 否则（即 head.next 就是当前线程），说明自己刚成为队首，可以尝试获取锁，返回 false

为什么不能只看 head.next != null 就认为要排队

因为 AQS 入队是“懒初始化”的：head 节点在第一个线程入队时才被创建，而 tail 更新和 next 指针设置存在微小时间差。比如：

Java Maven Common

Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。

下载

• 线程 A 入队，新建 node → 设置 tail = node → 还没来得及设 prev 和 head.next
• 此时 head != tail，但 head.next == null，若忽略此情况，线程 B 可能误判“没人排队”而抢锁，破坏公平性
• hasQueuedPredecessors() 把这种中间态也视为“存在潜在前驱”，强制后续线程排队，保证顺序语义

公平锁 vs 非公平锁的关键区别就在这里

非公平锁的 tryAcquire 直接尝试 CAS 获取状态，失败后再进队；公平锁则每次获取前必调 hasQueuedPredecessors()，宁可多一次 volatile 读，也要确保不绕过队列头部的线程。这也带来轻微性能开销，但换来了可预测的等待顺序。

立即学习“Java免费学习笔记（深入）”；