reentrantlock 可实现 trylock、限时等待、响应中断和灵活释放锁，而 synchronized 不支持；必须用 try-finally 确保 unlock() 执行，且仅在 lock() 成功后调用；公平锁降低吞吐量，应按需选用。
为什么不能直接用 synchronized 就得换 ReentrantLock
当需要尝试获取锁（不阻塞）、限时等待锁、响应中断、或按需释放锁顺序时，synchronized 无能为力。ReentrantLock 提供了这些能力，但代价是必须显式 lock() 和 unlock()，漏掉 unlock() 就会死锁。
典型场景包括：避免线程无限等待（如远程调用超时前放弃抢锁）、实现公平调度、或在 try 块中做多步操作后统一判断是否要释放锁。
lock() 必须配对 unlock()，且只能在 finally 块里写
这是最容易翻车的地方。写在 try 或 catch 里，一旦抛异常就跳过 unlock()；写在 if 分支里，路径一多就漏。
- 正确写法：始终把
unlock()放在finally块中，且确保lock()成功后才进finally - 错误写法：
lock()后直接跟unlock()（没进try-finally），或把unlock()放在catch里 - 注意：不能在
lock()失败时调用unlock()，会抛IllegalMonitorStateException
ReentrantLock lock = new ReentrantLock();
lock.lock(); // 成功才继续
try {
// 临界区操作
} finally {
lock.unlock(); // 这里必须执行，且只在 lock() 成功后才可能到达
}
用 tryLock() 实现非阻塞或限时抢锁
tryLock() 不会挂起线程，适合高并发下“抢不到就走”的策略；tryLock(long, TimeUnit) 则可用于设置最大等待时间，避免卡死。
- 返回
false表示当前未获得锁，不是异常，不要当成错误处理 - 如果用了带超时的
tryLock()，超时后线程不会被中断，但可配合Thread.interrupted()做协作取消 - 注意：超时单位必须用
TimeUnit，传整数毫秒会编译失败（方法重载不匹配）
if (lock.tryLock(100, TimeUnit.MILLISECONDS)) {
try {
// 拿到锁，执行业务
} finally {
lock.unlock();
}
} else {
// 抢锁失败，走降级逻辑（如返回缓存、抛限流异常）
}
公平锁与性能开销：别盲目设 true
new ReentrantLock(true) 开启公平模式后，线程按 FIFO 排队，避免饥饿，但吞吐量通常下降 20%~50%，因为每次都要检查队列头。
- 默认非公平锁更高效，适用于大多数场景（JVM 的
synchronized也是非公平的） - 只有明确遇到低优先级线程长期抢不到锁、且压测证实不公平导致问题时，才考虑公平锁
- 公平锁无法解决“锁粒度不合理”或“临界区过长”这类根本问题，加了也白加
真正难的是锁范围控制——比如该锁对象 A 却锁了整个类，或该分段锁却用了单个 ReentrantLock。这种设计偏差，比选公平还是非公平影响大得多。
