reentrantlock的公平性由构造参数决定且不可变：true为公平锁（按队列顺序获取），false或无参为非公平锁（默认，允许插队）；公平性仅影响lock()，trylock()始终非公平；选择依场景而定。
ReentrantLock 的公平性由构造时传入的布尔参数直接决定，且创建后不可更改。
构造参数含义明确
构造函数接受一个 boolean 类型参数，语义清晰：
- true → 公平锁：线程按 AQS 同步队列中的等待顺序获取锁，先到先得
- false 或 不传参 → 非公平锁（默认）：新线程可尝试直接抢占，可能插队
注意：new ReentrantLock() 和 new ReentrantLock(false) 完全等价，都是非公平锁；不存在“不传参即公平”的误解。
公平性绑定在锁实例生命周期内
公平性不是运行时属性，而是锁对象初始化时就固化的行为模式：
- 传
true时，内部 sync 字段被设为FairSync实例 - 传
false或无参时，sync 被设为NonfairSync实例 - 这两个子类重写了
tryAcquire方法，分别实现排队检查与直接抢占逻辑
没有 API 支持运行时修改公平性，任何反射篡改或字段替换都属未定义行为，可能导致状态错乱或死锁。
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
公平性只影响 lock() 方法
需特别注意：公平策略仅对 lock() 生效：
-
tryLock()（无参）永远是非公平尝试，忽略构造参数 -
tryLock(long, TimeUnit)虽然会阻塞等待，但仍是非公平抢占逻辑，只是加了超时控制
也就是说，即使用了 new ReentrantLock(true)，调用 tryLock() 仍可能“插队成功”，它不参与公平排队。
选择依据看场景需求
没有绝对优劣，关键匹配业务特征：
- 选公平锁：当必须避免线程饥饿、要求响应时间可预测（如实时调度、调试环境、配额分配）
- 选非公平锁：高并发读多写少、锁持有时间短、吞吐优先（绝大多数生产场景）
实测表明，在 16 线程争抢下，非公平锁平均耗时通常仅为公平锁的 20%～50%，但公平锁的延迟分布更集中。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
