ReentrantLock的公平性由AQS中acquire逻辑决定：公平锁在队列非空时直接入队，确保先到先得；非公平锁允许插队抢锁，但队列唤醒仍FIFO；默认非公平以提升吞吐量。
ReentrantLock 的公平性调度由其内部的 AQS（AbstractQueuedSynchronizer） 实现，核心在于是否启用公平模式（fair = true），而非“等待队列本身主动调度”。队列本身是 FIFO 链表，不参与决策；真正的公平性控制发生在线程尝试获取锁时的判断逻辑中。
公平锁：每次 acquire 都检查队列头部
当构造 ReentrantLock 时传入 true（如 new ReentrantLock(true)），它使用 FairSync 同步器。此时，任何线程调用 lock() 时：
- 先检查 AQS 等待队列是否非空（即是否有前序线程在排队）
- 若队列不为空，**直接放弃抢锁机会**，转而入队等待
- 只有当队列为空（或当前线程恰好是队首节点）时，才尝试 CAS 获取 state
这就保证了“先到先得”：新来的线程不会插队，必须排在队尾，等前面所有线程依次释放锁后才能执行。
非公平锁：允许插队，但队列仍是 FIFO
默认构造（new ReentrantLock()）使用 NonfairSync。它的 lock() 方法会先尝试一次 CAS 抢锁 —— 即使队列里已有等待线程，也允许刚唤醒或刚到达的线程“插队”成功。不过一旦抢锁失败，它仍会进入 AQS 队列，且入队操作严格遵循 FIFO：新节点总被添加到队尾，prev/next 指针维护链表顺序。
立即学习“Java免费学习笔记（深入）”；
注意：非公平锁的“不公平”仅体现在 首次尝试获取锁的时机上，队列内部调度始终按排队顺序唤醒（signal、unpark），从不跳过中间节点。
唤醒机制统一走 unpark，依赖队列顺序
无论公平与否，线程释放锁（unlock()）时都会调用 AQS 的 unparkSuccessor()：
- 从 head 开始向后找第一个状态为
0（即未取消）的节点 - 对该节点调用
LockSupport.unpark()
这个过程天然遵循 FIFO：总是唤醒最靠前的等待者。因此，队列的物理结构和唤醒逻辑本身是公平的；差异只存在于获取锁入口处是否允许绕过队列。
实际效果：公平性影响吞吐量与响应延迟
公平锁可降低线程饥饿概率，适合对响应时间敏感、等待时间需可控的场景（如实时任务）；但频繁检查队列+放弃 CAS 带来额外开销，吞吐量通常低于非公平锁。JDK 默认非公平，正是基于多数场景下性能优先的权衡。
