ReentrantLock 在高竞争场景下稳定的关键在于将控制权交还开发者。它基于AQS实现确定性队列管理，支持可中断、超时获取锁及多Condition精准唤醒，并依赖显式lock/unlock与try-finally保障资源不泄露。
ReentrantLock 在复杂线程竞争场景下能保持稳定，关键不在于“锁本身不会出错”，而在于它把控制权交还给开发者——通过可预测的底层机制、显式的行为契约和细粒度的干预能力，让高竞争逻辑可以被设计、观察和调优。
基于 AQS 的确定性等待队列管理
ReentrantLock 底层依赖 AbstractQueuedSynchronizer（AQS），其核心是用 volatile state 字段 + CLH 变种队列实现同步状态与线程调度。在高并发争抢时：
- state 值精确反映当前锁的重入次数（0 表示空闲，>0 表示被某线程持有且已重入多少次）
- 未获取到锁的线程会被封装为 Node 加入 FIFO 同步队列，排队顺序严格可追溯
- 非公平模式下虽允许“插队”，但仅限于当前锁刚释放、无等待线程时的瞬时抢占；一旦队列中有节点，后续请求一律排队，不会跳过已有等待者
- 公平模式则完全禁用插队，所有 acquire 请求都先检查队列是否为空，为空才尝试 CAS 获取，否则直接入队
可中断与超时机制避免无限阻塞
在复杂业务中，线程可能因外部依赖（如 RPC 超时、DB 锁等待）陷入长等待。synchronized 遇到这类情况只能死等，而 ReentrantLock 提供主动退出路径：
- lockInterruptibly()：线程在阻塞等待锁时，收到 interrupt 信号会立即抛出 InterruptedException 并退出等待，便于上层做熔断或降级
- tryLock(long, TimeUnit)：指定最大等待时间，超时返回 false，可结合重试策略或 fallback 逻辑，防止雪崩
- 这些操作不会破坏锁状态一致性——中断或超时失败后，锁仍由原持有者控制，无残留副作用
多 Condition 实现精准唤醒与解耦等待
当多个逻辑条件共用同一把锁（如生产者-消费者中的“队列非空”和“队列非满”），synchronized 的单一 wait/notify 容易误唤醒或漏通知。ReentrantLock 支持绑定多个 Condition：
立即学习“Java免费学习笔记（深入）”；
- 每个 Condition 对应独立的等待队列，signal() 只唤醒该条件队列中的线程
- 生产者调用 notFull.signal() 不会影响正在等待 notEmpty 的消费者
- 避免了 synchronized 中常见的 while + notifyAll 的低效轮询，提升响应精度和吞吐
显式 lock/unlock 与 try-finally 保障资源不泄露
虽然写法比 synchronized 略繁琐，但正是这种“显式性”成为稳定性基石：
- 必须配对调用 lock() 和 unlock()，否则会导致锁永远无法释放，引发大面积阻塞
- 规范写法强制使用 try-finally 或 try-with-resources（配合自定义 CloseableLock 封装），确保无论是否异常，unlock() 都被执行
- 这种可控性在嵌套锁、跨方法边界加锁、或需在 finally 块中做清理动作（如释放连接、关闭流）时尤为关键
