ReentrantLock的核心优势是显式可控，支持可中断锁等待、超时获取锁、公平性策略选择及多个Condition变量。它允许线程响应中断、限时抢锁、按需选择公平或非公平策略，并实现精准线程协作。
ReentrantLock 的核心优势在于“显式可控”——它把锁的获取、释放、等待策略等关键行为交到开发者手上，而不是依赖 JVM 隐式管理。
支持可中断的锁等待
当线程在等待锁时，synchronized 会一直阻塞，无法响应中断；而 ReentrantLock 提供 lockInterruptibly() 方法，允许线程在等待过程中被中断并抛出 InterruptedException。这在需要及时取消长时间等待（如超时任务、用户主动取消操作）的场景中非常关键。
- 适合构建响应式服务，比如 HTTP 请求中途断开后能快速释放资源
- 避免因锁等待导致线程池线程被长期占用
提供超时获取锁的能力
通过 tryLock(long timeout, TimeUnit unit)，线程可以在指定时间内尝试获取锁，超时则返回 false，不会无限阻塞。
- 防止死锁风险：比如两个线程分别持有 A 锁和 B 锁，又都试图获取对方的锁
- 便于实现“尽力而为”的并发逻辑，例如缓存更新失败时降级读取旧值
可选公平性策略
ReentrantLock 构造时可传入 true 启用公平锁，使线程按请求顺序排队获取锁；默认是非公平锁（性能更高，但可能造成个别线程长期得不到执行机会）。
立即学习“Java免费学习笔记（深入）”；
- 公平锁适用于对响应时间一致性要求高的场景，如金融交易系统中的订单处理
- 非公平锁更常见，吞吐量高，适合大多数业务系统
支持多个条件变量（Condition）
一个 ReentrantLock 可以创建多个 Condition 对象，每个 Condition 管理独立的等待队列。相比 synchronized 只能配合 wait()/notify() 使用单一隐式队列，它能实现更精细的线程协作。
- 例如生产者-消费者模型中，可分别为“缓冲区满”和“缓冲区空”定义不同 Condition
- 唤醒更精准：signal() 只唤醒等待该条件的线程，不会误唤醒其他类型等待者
