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

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

支持可中断的锁获取

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

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

支持超时获取锁

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

Alibabacloud Sdk Client Initialization For Java

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

下载

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

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

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

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

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

支持多条件变量（Condition）

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

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