ReentrantLock 是 Java 并发包中可重入、可中断、支持公平/非公平策略的显式锁，需精确控制临界区、必须用 try-finally 确保解锁、按场景选公平性、并善用 Condition 实现精准线程协作。

ReentrantLock 是 Java 并发包（java.util.concurrent.locks）中可重入、可中断、支持公平/非公平策略的显式锁，比 synchronized 更灵活，适合高并发下精细控制临界区。

明确临界区范围，避免锁粒度过大

高并发场景下，锁范围过大是性能瓶颈主因。应只包裹真正需要互斥访问的共享资源操作，而非整个方法或冗长逻辑。

• ❌ 错误示例：在锁内做远程调用、IO、复杂计算
• ✅ 正确做法：提前准备参数，锁内仅执行原子读-改-写（如更新账户余额、扣减库存）
• 例如：库存扣减只锁 if (stock > 0) { stock--; } 这两行，不包含日志记录或消息发送

必须搭配 try-finally 确保解锁

ReentrantLock 不具备 synchronized 的自动释放机制，一旦忘记 unlock 或异常跳出，会导致死锁或线程饥饿。

java-api-doc-generator

分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。

下载

• 务必在 finally 块中调用 lock.unlock()
• 不要依赖作用域或构造器自动释放
• 示例结构：

  lock.lock();
  try {
      // 访问临界资源
  } finally {
      lock.unlock(); // 无论是否异常，都释放
  }

按需选择公平性与响应性

默认是非公平锁（吞吐量高），但可能造成线程“饥饿”；开启公平模式（new ReentrantLock(true)）可保障等待时间长的线程优先获取锁，代价是性能下降约 10%–20%。

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

• 高吞吐场景（如高频计数器、缓存更新）：用非公平锁（默认）
• 对响应时间敏感或需避免饥饿（如任务调度队列、权限校验）：考虑公平锁
• 注意：公平锁不能完全杜绝饥饿，只是降低概率

善用条件变量（Condition）做精准等待/通知

相比 synchronized + wait/notify，ReentrantLock 支持多个独立 Condition，可实现更清晰的线程协作逻辑。

• 例如生产者-消费者中，分别定义 notFull 和 notEmpty 两个条件，避免虚假唤醒和无差别 notify
• 使用前必须先持有锁，wait 前自动释放，被 signal 后重新竞争锁
• 推荐用 awaitNanos(timeout) 或 awaitUntil(deadline) 实现超时控制，防止无限等待