reentrantlock 需手动管理锁的获取与释放，必须在 try 中 lock、finally 中 unlock；支持可中断、超时、公平性；需统一加锁顺序防死锁；通过 condition 实现精准唤醒。

ReentrantLock 可以替代 synchronized 实现更灵活的线程同步，但不是简单替换，关键在于理解它提供的额外能力并按需使用。

明确锁的获取与释放时机

synchronized 是 JVM 自动管理的隐式锁，进入同步块自动加锁、退出时自动释放；ReentrantLock 是显式锁，必须手动调用 lock() 获取、unlock() 释放。忘记 unlock 会导致死锁或资源长期被占。

• 必须在 try 块中获取锁，在 finally 块中释放锁，确保无论是否异常都能解锁
• 不要在构造方法或 return 语句后写 unlock —— 它可能根本不会执行
• 示例写法：

  lock.lock();
  try {
      // 临界区操作
  } finally {
      lock.unlock(); // 必须放在这里
  }

利用可中断、超时和公平性等高级特性

synchronized 不支持中断等待、无法设置获取锁超时、也不区分公平/非公平策略；ReentrantLock 提供了这些能力，适合对响应性或调度有要求的场景。

• 可中断等待：用 lockInterruptibly()，线程在等待锁时可响应 interrupt()，避免无限阻塞
• 带超时获取锁：用 tryLock(long, TimeUnit)，指定最多等待多久，返回 boolean 表示是否成功获得锁
• 公平锁选项：构造时传入 true（如 new ReentrantLock(true)），让等待最久的线程优先获取锁（默认是非公平的，性能略高但可能饥饿）

避免嵌套锁顺序不一致导致死锁

多个 ReentrantLock 组合使用时，若不同线程以不同顺序加锁（比如线程 A 先 lock1 再 lock2，线程 B 先 lock2 再 lock1），极易引发死锁。synchronized 虽也存在该问题，但因语法限制较难写出混乱顺序；而 ReentrantLock 更“自由”，风险更高。

• 所有线程应严格遵循**统一的加锁顺序**，例如按锁对象的哈希值排序后再依次获取
• 尽量减少同时持有多个锁；必要时考虑用 tryLock 配合回退逻辑（获取失败则释放已持锁并重试）
• 避免在持有锁期间调用外部不可控代码（如回调、用户传入的函数），防止意外反向加锁

注意锁的可重入性和条件变量配合

ReentrantLock 和 synchronized 一样支持可重入（同一线程可重复获取同一把锁），但它把 wait/notify 机制抽象为 Condition 对象，支持多个等待队列，更精细地控制唤醒范围。

• 用 lock.newCondition() 创建 Condition，代替 Object 的 wait/notify
• await() 替代 wait()，signal()/signalAll() 替代 notify()/notifyAll()
• 每次 await 前必须已持有对应锁，且 await 会自动释放锁；被唤醒后重新竞争锁，成功后才继续执行
• 一个 Lock 可关联多个 Condition，实现“精准唤醒”（例如生产者只唤醒消费者，不唤醒其他生产者）