ReentrantLock 提供比 synchronized 更灵活的锁机制，支持显式加解锁、可中断等待、超时获取、多条件变量及公平性选择，适用于需精细控制同步的复杂场景。
ReentrantLock 并不是用来“简化”同步的工具，而是提供比 synchronized 更灵活、更可控的锁机制。它不自动简化复杂场景，但通过明确的加锁/解锁、可中断等待、超时获取、公平性选择等能力，让开发者能更清晰、更可靠地构建线程同步逻辑。
用 lock() / unlock() 显式控制临界区
synchronized 隐式加锁、自动释放，容易因异常导致忘记释放（虽有 finally 保障，但写法冗长）。ReentrantLock 要求显式调用 lock() 和 unlock()，配合 try-finally 可确保锁一定被释放：
- 在 try 块开头调用 lock()，进入临界区
- 所有业务逻辑写在 try 块内，无论是否抛异常，finally 中都执行 unlock()
- 避免在构造函数、return 语句或循环中遗漏 unlock()
用 tryLock() + 超时避免无限阻塞
当线程可能长时间等待锁时（比如资源争抢激烈或持有者卡住），tryLock(long, TimeUnit) 可设超时，防止线程挂起：
- 返回 true 表示成功获取锁，可继续执行
- 返回 false 或抛出 InterruptedException，说明未拿到锁，可选择重试、降级或记录告警
- 适合定时任务、RPC 调用、缓存更新等对响应时间敏感的场景
用 newCondition() 实现精准线程协作
synchronized 只能搭配一个 wait()/notify() 队列，而 ReentrantLock 可创建多个 Condition 实例，实现不同条件下的独立唤醒：
立即学习“Java免费学习笔记（深入）”；
- 比如生产者-消费者模型中，用 notFull 和 notEmpty 两个 Condition 分别管理缓冲区满/空状态
- signal() 只唤醒等待该 Condition 的线程，不会误唤醒其他无关线程
- 避免 synchronized 下 notifyAll() 引发的“惊群效应”和无效唤醒
按需启用公平锁，减少饥饿但注意性能代价
默认非公平锁吞吐高，但可能导致某些线程长期拿不到锁；构造时传入 true 可启用公平模式：
- 公平锁按 FIFO 顺序排队，提升线程调度可预测性
- 但每次获取锁都要检查队列，带来额外开销，吞吐通常下降 10%–20%
- 仅在确实存在明显饥饿（如低优先级任务总被挤占）且性能可接受时启用
