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 实例，实现分组等待与精准唤醒。

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

立即学习“Java免费学习笔记（深入）”；

• 例如生产者-消费者模型中：notFull 和 notEmpty 两个条件变量，互不干扰
• 写法：

  private final ReentrantLock lock = new ReentrantLock();
  private final Condition notEmpty = lock.newCondition();
  private final Condition notFull = lock.newCondition();
  <p>// 消费者等待数据
  lock.lock();
  try {
  while (queue.isEmpty()) notEmpty.await();
  // 取数据...
  } finally {
  lock.unlock();
  }</p><p>// 生产者添加数据后只唤醒消费者
  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 自动管理，恰恰是它在绝大多数业务代码中不可替代的底层底气。