Lock 提供 tryLock()、lockInterruptibly()、超时获取锁及多 Condition 精准唤醒等 synchronized 不具备的能力；必须用 try-finally 保证 unlock()，不可用 try-with-resources；非公平锁性能更优，公平锁仅适用于响应敏感且压测验证有效的场景；Condition 需按业务语义分设，避免混用。
Lock 接口比 synchronized 多了哪些实际可用的能力
直接说结论：Lock 不是为了“替代”而替代，而是当你需要 synchronized 做不到的事时才用。比如：尝试获取锁但不想阻塞（tryLock()）、可中断的锁等待（lockInterruptibly()）、超时获取锁（tryLock(long, TimeUnit)）、或绑定多个 Condition 实现精准唤醒。
常见误用是拿 ReentrantLock 简单套一层就当“升级”，结果忘了 unlock() 必须手动调用，反而引发死锁或资源泄漏。
必须用 try-finally 保证 unlock() 执行
synchronized 是 JVM 自动释放的，Lock 不是。一旦忘记 unlock() 或在临界区抛异常没兜住，锁就永远卡住。
正确写法只有一种主流模式：
立即学习“Java免费学习笔记（深入）”；
Lock lock = new ReentrantLock();
lock.lock();
try {
// 临界区操作
} finally {
lock.unlock(); // 即使抛异常也必须执行
}
别用 try-with-resources（Lock 不实现 AutoCloseable）；也别把 unlock() 放在 catch 里——finally 是唯一可靠位置。
new ReentrantLock(true) 开启公平锁要谨慎
默认构造的 ReentrantLock 是非公平的，性能更好；加 true 参数变成公平锁后，线程按 FIFO 排队，但吞吐量通常下降 20%~50%。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
公平锁只在以下情况真正有用：
- 业务逻辑对响应时间波动极度敏感（比如实时交易系统里不能容忍某线程饿死）
- 你已确认锁竞争激烈且线程调度延迟是瓶颈
- 压测证明公平策略确实改善了你的 SLA 指标
多数 Web 应用、缓存更新、日志写入等场景，用默认非公平锁更稳。
Condition 替代 wait()/notify() 时要注意唤醒粒度
synchronized 只能配一个隐式监视器，所以 notifyAll() 经常“一锅端”；Lock 配 Condition 可以建多个，实现“只唤醒关心这个条件的线程”。
典型错误是复用同一个 Condition 实例处理不同语义的等待：
Lock lock = new ReentrantLock(); Condition notFull = lock.newCondition(); // ✅ 生产者等“不满” Condition notEmpty = lock.newCondition(); // ✅ 消费者等“不空” // 别这么写： // Condition c = lock.newCondition(); // ❌ 一个 Condition 混用两种等待
每个 Condition 应该对应一种明确的业务等待条件，否则 signal() 会唤醒错人，导致虚假唤醒或死等。
复杂点在于：Condition 的 await() 会自动释放锁，但返回前会重新竞争锁——如果此时有其他线程正持有锁并长时间运行，你的线程可能卡在“醒来后抢不到锁”的状态，看起来像假死。这不是 bug，是设计使然，得靠减少临界区耗时来缓解。
