reentrantlock 比 synchronized 更灵活，支持可中断锁获取（lockinterruptibly）、超时获取锁（trylock）、公平/非公平模式选择及多个condition变量。

ReentrantLock 比 synchronized 更灵活，核心在于它把“锁的获取与释放”从 JVM 的隐式语义，变成了 Java 类库中可编程、可控制的对象行为。

支持可中断的锁获取

synchronized 在等待锁时无法响应中断，线程会一直阻塞；而 ReentrantLock 的 lockInterruptibly() 方法允许线程在等待过程中被中断并抛出 InterruptedException，便于实现超时重试、任务取消等逻辑。

• 使用 lockInterruptibly() 替代 lock()，在 catch 中处理中断
• 适合需要响应用户取消操作或服务优雅停机的场景

支持超时获取锁

ReentrantLock 提供 tryLock(long, TimeUnit) 方法，在指定时间内尝试获取锁，超时则返回 false。synchronized 完全不支持这种“尽力而为”的语义。

Java Development Manual

Java开发手册规约集合，基于阿里巴巴Java开发手册（嵩山版）。 涵盖7大维度：编程规约、异常日志、单元测试、安全规约、MySQL数据库、工程结构、设计规约。 当用户需要：(1) 编写或审查Java代码 (2) 检查命名/代码规范 (3) 处理异常和日志 (4) 编写单元测试 (5) 安全编码 (6) 数据库设...

下载

• 避免无限期等待，防止死锁蔓延或资源耗尽
• 常用于构建非阻塞算法或带降级策略的服务调用
• 示例：tryLock(3, SECONDS) 表示最多等 3 秒，拿不到就走备用路径

支持公平与非公平两种模式

ReentrantLock 构造时可传入 fair = true，启用公平锁（FIFO 等待队列），让等待最久的线程优先获取锁；synchronized 始终是非公平的，且不可配置。

• 公平锁降低饥饿概率，但吞吐量通常更低（需维护队列、更多上下文切换）
• 默认非公平模式更高效，符合大多数高并发场景需求
• 是否开启公平性需结合业务对响应时间稳定性的要求权衡

支持多条件变量（Condition）

synchronized 只能配合一个隐式的 wait/notify 队列；ReentrantLock 可通过 newCondition() 创建多个独立的 Condition 对象，实现精准唤醒。

• 例如生产者-消费者模型中，可分别定义 notFull 和 notEmpty 两个条件
• signal() 只唤醒等待该 Condition 的线程，避免 notify() 的“惊群效应”
• 提升线程调度精度，减少无谓的唤醒和竞争

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南