ReentrantLock的公平锁与非公平锁核心区别在于获取锁时是否检查同步队列中是否有等待者：公平锁先检查队列，有等待者则入队；非公平锁直接CAS抢占，失败才入队。两者均基于AQS，释放逻辑相同。
ReentrantLock 的公平锁与非公平锁，核心区别在于线程获取锁时是否检查同步队列中是否有等待者——有则排队（公平），无则直接尝试抢占（非公平）。这个行为由构造函数传入的 fair 参数控制，默认为 false（非公平）。
公平锁：先到先得，严格按 FIFO 排队
公平模式下，每次调用 lock() 时，线程会先检查 AQS 同步队列中是否已有等待节点。如果有，当前线程必须入队，不和队首竞争；只有队列为空时，才尝试 CAS 抢占锁。
- 实现逻辑在
FairSync.tryAcquire(int)中：先调用hasQueuedPredecessors()判断自己前面是否有等待者 - 该方法本质是检查
head != tail且head.next是否非空且不是当前线程 —— 即队列非空且头结点后还有人排队 - 若返回
true，说明有人在等，当前线程放弃抢占，走acquireQueued(addWaiter(Node.EXCLUSIVE), arg)入队阻塞
非公平锁：插队优先，能抢就抢
非公平模式下，线程调用 lock() 会**先尝试一次 CAS 抢锁**，不管队列里有没有人。抢成功就直接持有锁；失败才去检查状态、入队。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 实现逻辑在
NonfairSync.lock()：第一步就是compareAndSetState(0, 1)，成功则setExclusiveOwnerThread(Thread.currentThread()) - 即使此时队列里已有多个等待线程，新来的线程仍可能插队成功（尤其在锁刚释放瞬间）
- 这种“插队”提升了吞吐量，但可能导致个别线程长期饥饿（不过 JDK 实现中实际饥饿概率很低）
两者共用同一套 AQS 和等待队列结构
公平与非公平只是获取锁的入口策略不同，底层都基于 AQS 的 state 状态变量、exclusiveOwnerThread 和 CLH 队列。释放锁（unlock()）逻辑完全一致：
- 调用
sync.release(1)，先tryRelease()将state减为 0 并清空持有线程 - 再唤醒队列中第一个有效等待节点（
unparkSuccessor(head)） - 被唤醒的线程再次尝试获取锁，此时又回到各自公平/非公平的
tryAcquire逻辑
怎么选？看场景需求
非公平锁是默认选择，因为大多数场景下它吞吐更高、延迟更低；公平锁适合对响应时间一致性要求高、或需避免潜在饥饿的业务逻辑。
- 高并发短临界区（如计数器更新）→ 用非公平锁（默认）
- 长耗时操作 + 多线程轮询资源（如任务调度器）→ 可考虑公平锁，让等待更可预测
- 注意：公平锁不能完全杜绝饥饿，但显著降低概率；且性能开销略大（每次 lock 多一次队列检查）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
