多数场景优先用 synchronized；仅当需 tryLock、可中断等待、公平锁或多个 Condition 时才选 ReentrantLock，且必须手动在 finally 中 unlock，否则易死锁。
ReentrantLock 和 synchronized 到底该选谁
多数场景下，synchronized 足够用，且更安全；只有当你需要 tryLock()、可中断等待、公平锁或绑定多个 Condition 时，才值得换成 ReentrantLock。别为了“看起来高级”而替换——它不自动释放锁，写错就死锁。
ReentrantLock 必须手动 unlock() 的坑
忘记在 finally 块中调用 unlock() 是最常见错误，会导致锁永远无法释放，后续线程全部阻塞。Java 不会像 synchronized 那样在作用域退出时自动清理。
- 必须把
lock()放在try外面，unlock()放在finally里 - 不能在构造函数或异常未捕获的分支中提前 return，否则
finally不执行 - 如果用在循环里，每次迭代都要独立完成 lock/unlock，不能跨迭代复用
ReentrantLock lock = new ReentrantLock();
lock.lock();
try {
// 业务逻辑
} finally {
lock.unlock(); // 这行绝不能少，也不能写在 try 或 catch 里
}
公平锁参数 true 的代价很大
创建 ReentrantLock 时传 true 启用公平模式（new ReentrantLock(true)），会让线程按请求顺序排队，但吞吐量通常下降 2–5 倍。JVM 默认的非公平模式（false 或无参构造）允许插队，反而更高效。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 公平锁只在极少数对响应时间敏感、且能容忍低吞吐的场景有用（如实时任务调度）
- 高并发 Web 服务、数据处理流水线一律用默认非公平模式
-
isFair()返回true并不表示当前没线程在等，只是说明构造时设了公平参数
Condition 替代 wait/notify 时的线程唤醒控制
ReentrantLock 配合 Condition 可以实现比 Object.wait() 更精细的唤醒策略，比如只唤醒“等待读”的线程，而不惊动“等待写”的线程。
立即学习“Java免费学习笔记（深入）”；
- 一个
ReentrantLock可创建多个Condition实例，各自维护独立等待队列 -
condition.signal()不保证唤醒哪个线程，signalAll()才全唤醒 - 必须在持有锁的前提下调用
await()，否则抛IllegalMonitorStateException - 和
wait()一样，await()会释放锁，并在被唤醒后重新竞争锁
ReentrantLock lock = new ReentrantLock();
Condition notFull = lock.newCondition();
Condition notEmpty = lock.newCondition();
lock.lock();
try {
while (queue.size() == MAX_SIZE) {
notFull.await(); // 释放锁，进入 notFull 等待队列
}
queue.add(item);
notEmpty.signal(); // 只唤醒一个等待消费的线程
} finally {
lock.unlock();
}
用 ReentrantLock 最容易忽略的不是语法，而是锁的生命周期管理——它不像 synchronized 那样“进块即加，出块即放”，你得自己盯住每一对 lock()/unlock()，尤其是在有多个 return 路径、嵌套 try 或带异常重试的逻辑里。 
