ReentrantLock替代synchronized使用教程

ReentrantLock 并非只是 synchronized 的简单升级版，而是一个功能更强大、控制更精细的显式锁工具——它要求开发者手动管理加锁与释放（必须在 try 中 lock、finally 中 unlock），同时赋予线程同步前所未有的灵活性：支持可中断等待、带超时的锁获取、公平性策略选择，并通过 Condition 实现多等待队列下的精准唤醒；但这份自由也带来更高风险，如因加锁顺序不一致引发死锁，或因疏忽导致锁泄露，因此真正掌握 ReentrantLock，关键在于理解其设计意图、严守使用规范，并在响应性、可控性和复杂度之间做出明智取舍。

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，实现“精准唤醒”（例如生产者只唤醒消费者，不唤醒其他生产者）

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《ReentrantLock替代synchronized使用教程》文章吧，也可关注golang学习网公众号了解相关技术文章。