ReentrantLock必须手动释放，需在finally块中调用unlock()；lock()阻塞获取，tryLock()支持非阻塞或超时；公平锁性能差且仅影响队列线程；Condition实现多条件等待；多数场景优先用synchronized。
ReentrantLock必须手动释放，否则会死锁
和synchronized不同，ReentrantLock不会自动释放锁——哪怕发生异常、提前return或线程中断，锁都还被占着。这是最常踩的坑，直接导致后续线程永久阻塞。
- 必须把
unlock()放在finally块里，确保无论是否异常都会执行 - 不能只在
try末尾调用unlock()，那样一旦中间抛出异常就跳过了 - 不要在
catch里释放锁——可能根本没拿到锁就进了catch，此时调用unlock()会抛IllegalMonitorStateException
ReentrantLock lock = new ReentrantLock();
lock.lock();
try {
// 业务逻辑，可能抛异常
doSomething();
} finally {
lock.unlock(); // 唯一安全的位置
}
lock()和tryLock()的区别决定阻塞行为
lock()是阻塞式获取，拿不到锁就一直等；tryLock()是非阻塞或限时等待，更适合避免无限等待场景。
-
tryLock()无参版本立即返回：true表示抢到锁，false表示当前不可用，不等 -
tryLock(long, TimeUnit)可设超时：比如tryLock(100, TimeUnit.MILLISECONDS)最多等100ms，超时返回false - 用
tryLock()时，一定要检查返回值——忘记判断if (!lock.tryLock()) return;会导致后续代码在无锁状态下执行，数据错乱
new ReentrantLock(true)开启公平锁要慎重
默认构造函数创建的是非公平锁，即允许插队；传true可启用公平模式：new ReentrantLock(true)。
- 公平锁保证等待时间最长的线程优先获取，但性能下降明显（需维护同步队列+额外CAS开销）
- 高并发下，公平锁吞吐量通常比非公平锁低30%以上，JDK文档也明确建议“仅在有明确理由时才启用”
- 公平性只影响等待队列中的线程，不阻止新线程立刻抢到刚释放的锁（这点常被误解）
Condition配合await()/signal()替代Object的wait/notify
ReentrantLock通过newCondition()获得Condition对象，实现更灵活的线程协作，比synchronized里的wait/notify更可控。
立即学习“Java免费学习笔记（深入）”；
- 一个
ReentrantLock可绑定多个Condition，比如生产者用notFull，消费者用notEmpty，避免虚假唤醒干扰 -
await()会自动释放锁并挂起线程；被signal()唤醒后，必须重新竞争锁，成功后才继续执行 - 别在
synchronized块里调用Condition方法——会抛IllegalMonitorStateException，它只认自己关联的ReentrantLock
真正难的不是写对语法，而是判断该不该用ReentrantLock——多数简单同步场景，synchronized更安全、JIT优化更好；只有需要尝试获取、超时控制、多条件等待或公平性策略时，才值得引入显式锁。
