ReentrantLock 应优先选用非公平锁以提升吞吐量，合理利用可中断、tryLock超时、分段锁和Condition等特性，避免锁内耗时操作。
ReentrantLock 能比 synchronized 更精细地控制锁行为，尤其适合高并发、频繁调用的资源操作场景。关键不是“用了就快”，而是合理利用它的可中断、可轮询、公平性配置和条件变量等特性，避免锁竞争放大或线程阻塞拖慢整体吞吐。
按需选择公平性与非公平性
默认非公平锁（构造时传 false 或无参）性能更好，适用于大多数高频调用场景——它允许刚释放锁的线程大概率立即重入，减少上下文切换。而公平锁（new ReentrantLock(true)）按等待顺序分配，虽更“公正”，但会显著增加线程调度开销，吞吐量通常下降 20%～40%。除非业务强要求请求顺序（如排队类服务），否则不建议开启公平模式。
- 高频读写操作（如缓存更新、计数器累加）优先用非公平锁
- 若发现大量线程长时间阻塞在
lock()，再结合getQueueLength()判断是否真存在不公平饥饿，而非直接切公平模式
用 tryLock() 避免无限阻塞
对响应时间敏感的操作（如实时接口、定时任务中的资源检查），不应盲目调用 lock() 等待。改用带超时的 tryLock(long, TimeUnit)，失败时快速降级或重试，防止一个慢操作拖垮整条链路。
- 示例：更新共享配置时，尝试获取锁 50ms，失败则返回旧值并异步触发刷新
- 注意：必须在
finally中调用unlock()，且仅当tryLock()返回true时才解锁
拆分锁粒度，减少竞争热点
单个 ReentrantLock 保护整个资源池（如全局 Map）是常见瓶颈。应按访问特征做分段或哈希隔离，比如用 ConcurrentHashMap + 分段锁，或为不同 key 分配独立 Lock 实例（如 Map<key lock></key> 配合 computeIfAbsent 懒创建）。
立即学习“Java免费学习笔记（深入）”；
- 例如用户维度操作：用
locks.computeIfAbsent(userId, k -> new ReentrantLock())获取专属锁 - 避免锁对象被意外共享（如 static Lock 或复用同一实例），否则逻辑隔离失效
配合 Condition 实现精准唤醒
当资源操作涉及等待/通知（如生产者-消费者模型），用 Condition 替代 Object.wait()/notify()，可避免虚假唤醒、支持多等待队列，提升唤醒效率。
- 定义多个 Condition（如
notEmpty、notFull），只唤醒关心该状态的线程 - 务必在 while 循环中检查条件，且
await()前已持有锁，signal()后仍保持锁直到完成必要操作
不复杂但容易忽略：锁的生命周期要和业务边界严格对齐，避免在锁内做远程调用、I/O 或长耗时计算。真正影响性能的，往往不是锁本身，而是锁里不该做的事。
