公平锁要求线程必须按CLH队列FIFO顺序获取锁，即仅当节点为队首时才尝试CAS抢锁；非公平锁则允许新线程直接CAS抢锁，可能插队，提升吞吐但牺牲顺序性。
公平锁的 acquire 流程依赖 CLH 队列的 FIFO 顺序
公平锁的核心约束是：线程必须排在 CLH 队列尾部，且仅当自己是队首节点时才尝试获取锁。这意味着即使锁刚被释放，刚到的线程也不能插队——它得先入队，等前面所有节点都轮完一遍。
关键点在于 hasQueuedPredecessors() 方法的判断逻辑：
- 它检查当前线程节点是否为队首（即前驱节点是 head）
- 若不是，则直接返回
true，触发acquireQueued()进入阻塞等待 - 这个检查发生在 CAS 尝试抢锁之前，彻底堵死了“唤醒即抢到”的捷径
所以公平锁下，ReentrantLock lock = new ReentrantLock(true) 的行为是可预测的：线程 T0 先调用 lock()，T1/T2 陆续到达，最终执行顺序几乎总是 T0 → T1 → T2，除非发生中断或超时。
非公平锁的 tryAcquire 跳过队列检查直接 CAS 抢锁
非公平锁（默认构造，new ReentrantLock()）在 acquire() 入口就多了一次“插队机会”：它先不查队列，直接调用 tryAcquire() 尝试 CAS 修改 state。
这导致两个典型现象：
- 刚释放锁的瞬间，下一个唤醒的线程还没来得及入队，新来的线程可能抢先抢到锁（
compareAndSwapInt成功） - 即使 CLH 队列里已有等待节点，新线程仍会尝试抢锁；只有抢失败了，才老老实实调用
addWaiter()入队 - 所以你可能看到线程 T2 在 T1 之前获得锁——这不是 bug，是设计使然
这种“唤醒 + 插队”双重机会，让非公平锁吞吐更高，但牺牲了调度确定性。
CLH 队列本身不区分公平/非公平，区别全在 acquire 逻辑分支
AQS 的 CLH 队列始终是 FIFO 双向链表结构，节点插入、唤醒、取消都遵循相同规则。所谓“公平”或“非公平”，完全由子类 FairSync 和 NonfairSync 对 tryAcquire() 的重写决定。
具体差异体现在：
-
FairSync.tryAcquire(int acquires)开头必调hasQueuedPredecessors() -
NonfairSync.tryAcquire(int acquires)直接走compareAndSwapState(0, acquires) - 两者共用同一套
acquireQueued()，即入队后的等待逻辑完全一致
换句话说：CLH 是舞台，公平性是导演给演员写的剧本——换剧本不换布景。
实际调试时注意 state 和 waitStatus 的耦合关系
别只盯着队列结构，state 字段和节点的 waitStatus 才真正驱动调度。例如：
- 一个节点
waitStatus == Node.SIGNAL表示它已准备好被唤醒，但能否执行取决于state是否为 0 - 非公平锁下，
state可能刚从 1 变成 0，同时多个线程在 CAS，只有一个成功；其余失败者才去读waitStatus决定是否 park - 公平锁下，即便
state == 0，也要先确认自己是队首，否则不碰state
最容易忽略的是：CLH 队列里节点的生命周期和线程状态并不严格一一对应——比如中断或超时取消的节点，waitStatus 会设为 CANCELLED，但它仍留在队列中，只是后续节点会跳过它。这点在分析 dump 日志时特别容易误判。
