ReentrantLock 的核心优势是“更可控”而非“更强大”，适用于需响应中断、公平锁、多条件变量唤醒、尝试获取锁等场景，但需手动管理锁释放，责任更重。
ReentrantLock 相比 synchronized 的核心优势不是“更强大”，而是“更可控”——当你需要跳出“默认行为”时，它才真正派上用场。日常开发中，synchronized 仍是首选；但遇到特定瓶颈或协作需求，ReentrantLock 就是那个能精准拆弹的工具。
需要响应中断？用 lockInterruptibly()
当一个线程在等待锁时被其他线程调用 interrupt()，synchronized 完全无视，继续傻等；而 ReentrantLock 可以立刻抛出 InterruptedException 并退出，避免无限挂起。
- 典型场景：定时任务、RPC 调用超时、线程池中任务主动取消
- 错误写法：
lock.lock()—— 即使被中断也会阻塞到底 - 正确写法：
try { lock.lockInterruptibly(); // 临界区 } catch (InterruptedException e) { Thread.currentThread().interrupt(); // 恢复中断状态 return; // 或抛出、记录、清理资源 } finally { if (lock.isHeldByCurrentThread()) lock.unlock(); } - 注意：
lockInterruptibly()必须配合try-catch，且不能放在finally中释放（否则可能锁还没拿到就执行unlock()报IllegalMonitorStateException）
要按排队顺序分配锁？启用公平模式
synchronized 始终是非公平的——新来的线程可能插队成功，导致等待久的线程“饿死”。ReentrantLock 允许构造时传 true 启用公平策略：
ReentrantLock fairLock = new ReentrantLock(true);- 公平锁保障 FIFO，适合对响应时间敏感、需避免长等待的场景（如金融交易日志写入）
- 但代价明显：吞吐量通常下降 20%~50%，因为每次都要检查队列头
- 非公平锁（默认）仍是多数场景更优选择，JDK 优化后插队成功率高、性能好
要唤醒指定线程组？绑定多个 Condition
synchronized 只能用 wait()/notifyAll()，要么随机唤醒一个，要么全叫起来——容易引发“惊群效应”。ReentrantLock 支持创建多个独立 Condition 实例，实现分组等待与精准唤醒。
立即学习“Java免费学习笔记（深入）”；
- 例如生产者-消费者模型中：
notFull和notEmpty两个条件变量，互不干扰 - 写法：
private final ReentrantLock lock = new ReentrantLock(); private final Condition notEmpty = lock.newCondition(); private final Condition notFull = lock.newCondition();
// 消费者等待数据 lock.lock(); try { while (queue.isEmpty()) notEmpty.await(); // 取数据... } finally { lock.unlock(); }
// 生产者添加数据后只唤醒消费者 lock.lock(); try { queue.offer(item); notEmpty.signal(); // 不是 signalAll() } finally { lock.unlock(); }
- 关键点：
Condition必须由同一把ReentrantLock创建，且await()前必须已持有该锁
想试探性获取锁？用 tryLock() 避免阻塞
某些场景下，“拿不到锁就干点别的”比“死等”更合理——比如缓存更新失败时降级查 DB，或重试前先判断是否已被其他线程处理。
if (lock.tryLock()) { ... } else { /* 做备选方案 */ }- 还可带超时：
if (lock.tryLock(100, TimeUnit.MILLISECONDS)) { ... } - 注意：
tryLock()成功后仍需在finally中配对unlock()，否则会永久占用锁 -
synchronized完全没有对应能力，只能硬等
真正容易被忽略的是：ReentrantLock 的灵活性是以责任为代价的。忘了 unlock()、在未持锁时调用 unlock()、或在异常路径中漏掉释放逻辑，都会直接导致死锁。而 synchronized 的 JVM 自动管理，恰恰是它在绝大多数业务代码中不可替代的底层底气。
