不能只靠继承AQS就实现公平锁，必须重写tryAcquire并在其中调用hasQueuedPredecessors()——这是AQS提供的唯一公平性判定依据，漏掉它，公平性就失效。
直接说结论：不能只靠继承 AQS 就“实现”公平锁，必须重写 tryAcquire 并在其中调用 hasQueuedPredecessors() —— 这是 AQS 提供的唯一公平性判定依据，漏掉它，公平性就失效。
为什么 hasQueuedPredecessors() 是公平锁的命门
公平锁的本质不是“先来先得”的口头承诺，而是每次尝试获取锁时，都检查自己前面是否已有等待线程。AQS 不维护全局时间戳或插入序号，它只靠 hasQueuedPredecessors() 判断：
– 返回 true 表示队列非空且当前线程不是队首等待者（即有前驱）
– 此时应放弃 CAS 抢占，进入阻塞队列
– 这个方法内部只检查 head != tail 且 head.next 是否指向有效节点，开销极小但语义精准
常见错误是绕过它，比如在 tryAcquire 里只判断 state == 0 就 CAS，这和非公平锁没区别。
tryAcquire 必须同时处理可重入 + 公平性 + 状态变更
公平锁的 tryAcquire 不是简单判断“锁空闲”，而要分三步原子检查：
- 如果
state == 0，再调用hasQueuedPredecessors()；仅当返回false（即无前驱）才尝试compareAndSetState(0, acquires) - 如果
state > 0且getExclusiveOwnerThread() == currentThread，说明可重入，直接setState(state + acquires) - 任何状态不匹配（如
state > 0但持有线程不是当前线程），立即返回false，交由acquire框架入队
注意：不可在 state == 0 分支里省略 hasQueuedPredecessors() 调用；也不可在重入分支里忽略 state 溢出检查（nextc ）。
别忘了设置 exclusiveOwnerThread 和正确使用 setState
AQS 自身不管理锁持有线程，全靠子类在获取成功后显式调用 setExclusiveOwnerThread(Thread)。漏掉这句，isHeldExclusively() 和重入判断都会失效。
另外：
– setState(int) 是普通赋值，无原子性，只能用于已确认线程安全的场景（如重入时）
– compareAndSetState(int, int) 才是 CAS 原子操作，仅用于初始抢占
– 错把 setState 当成 CAS 用，会导致并发下 state 错乱，比如两个线程同时重入，state 只加了 1 次
公平锁的性能代价藏在 acquire 入口处
公平锁的 lock() 方法必须直接调用 acquire(1)，不能像非公平锁那样先 compareAndSetState(0, 1) 再 fallback —— 否则就破坏了“排队优先”原则。
这意味着：每个 lock() 调用至少触发一次队列检查（hasQueuedPredecessors()），即使锁空闲。高竞争下，这个检查本身虽快，但会显著增加 cache line 争用（因读 head/tail）。实际压测中，公平锁吞吐量通常比非公平锁低 20%~40%，这不是 bug，是设计取舍。
真正容易被忽略的是：一旦你写了公平逻辑，就必须全程守住“不插队”边界——包括 tryLock()、lockInterruptibly() 等所有入口，它们底层最终都流向 tryAcquire，不能有一处绕过 hasQueuedPredecessors()。
