ReentrantLock 仅在需可中断、超时、多条件变量或锁状态查询时才替代 synchronized；必须手动 unlock 且仅限 finally 块中调用，公平模式显著降低吞吐，锁粒度与业务原子性须严格匹配。
Java 中 Lock 接口不是“比 synchronized 更好”的万能替代，而是为特定并发控制需求提供的显式、可中断、可超时、可多条件的锁
什么时候必须用 ReentrantLock 而不是 synchronized
只有当需要以下能力之一时，才考虑替换：synchronized 无法满足这些需求：
-
lockInterruptibly()：线程在等待锁时可响应Thread.interrupt() -
tryLock(long, TimeUnit)：带超时的非阻塞加锁，避免无限等待 - 一个
Lock实例关联多个Condition（如生产者/消费者各自独立唤醒） - 需要查询锁状态，例如
isLocked()、getHoldCount()（仅限调试或监控）
普通临界区保护、简单同步计数器、对象级互斥，synchronized 更简洁安全，JVM 还做了锁优化（偏向锁、轻量级锁）。
ReentrantLock 必须手动 unlock()，且只能在 finally 块中做
忘记释放、异常跳过释放、在错误作用域释放，都会导致锁永远被持有着——后续所有线程卡死在 lock()。这不是警告，是高频线上事故原因。
Lock lock = new ReentrantLock();
lock.lock();
try {
// 业务逻辑，可能抛异常
doSomething();
} finally {
lock.unlock(); // ✅ 唯一安全位置
}
不能写成：
-
if (lock.tryLock()) { ... unlock(); }—— 没有finally，异常时漏解锁 -
lock.lock(); unlock();放在try外 —— 可能锁都没拿到就调了unlock()，抛IllegalMonitorStateException
ReentrantLock(true) 的公平性代价远超预期
构造时传 true 启用公平模式，会让等待最久的线程优先获取锁。但实际中几乎不推荐：
- 吞吐量下降 2–10 倍（取决于争用强度），因为要维护 FIFO 队列并频繁检查
- 仍不能保证“绝对公平”：刚唤醒的线程和新来的线程仍存在竞争窗口
- 公平锁无法解决锁顺序死锁问题，也不能替代正确的锁获取顺序设计
默认非公平模式（new ReentrantLock()）在绝大多数场景下更合理——它允许“插队”，但显著提升 CPU 缓存利用率和整体吞吐。
别把 Lock 当成 synchronized 的语法糖来用
常见反模式：
- 在每个 getter/setter 上套
lock/unlock—— 锁粒度太细，反而因上下文切换拖慢性能 - 跨方法持有锁（比如
lock()在 A 方法，unlock()在 B 方法）—— 控制流复杂后极易漏释放或重入出错 - 用
ReentrantLock替代volatile做可见性保障 —— 锁能保证可见性，但过度；volatile更轻量且语义清晰
真正关键的是：锁的边界必须与业务原子性一致。比如“扣库存 + 记日志”是一个不可拆分操作，那就该包在一个 lock 块里；如果只是读一个计数器，AtomicInteger 往往更合适。
