reentrantlock需手动配对acquire/release，必须用try-finally确保unlock；默认非公平锁性能更优；condition替代wait/notify须用while重检条件；仅在需超时、中断响应或多个条件队列时选用。
ReentrantLock 必须手动 acquire() 和 release()
和 synchronized 自动加锁解锁不同，ReentrantLock 是显式锁，不配对调用就会导致死锁或资源泄露。最常见错误是只在正常流程里 lock.lock()，但异常时没释放。
- 必须把
lock()放在try前，unlock()放在finally块中 - 不能在构造函数或初始化块里直接
lock()，否则可能锁住未完成初始化的对象 -
lock.tryLock()可设超时，避免无限等待；lock.isHeldByCurrentThread()用于调试判断当前线程是否已持锁
ReentrantLock lock = new ReentrantLock();
lock.lock(); // 必须配对
try {
// 临界区操作
} finally {
lock.unlock(); // 即使抛异常也必须执行
}
公平锁与非公平锁的实际差异
默认创建的是非公平锁（new ReentrantLock()），它允许插队：新线程可能比等待队列里的老线程更早获取锁。公平锁（new ReentrantLock(true)）按 FIFO 调度，但吞吐量明显下降，且仍不保证绝对“公平”——比如刚唤醒的线程和刚调用 lock() 的线程竞争时，JVM 调度仍可能让后者胜出。
- 高并发写场景下，非公平锁通常性能更好，尤其临界区短、争抢频繁时
- 公平锁仅在需要明确响应顺序的业务逻辑中考虑（如任务调度器、资源分配器）
- 公平性开关不可动态修改，必须在构造时确定
Condition 替代 wait/notify 的正确姿势
ReentrantLock 不支持 wait()/notify()，要用 lock.newCondition() 获取 Condition 实例。常见错误是多个线程共用同一个 Condition 却没做条件重检，或在未持有锁时调用 await() 导致 IllegalMonitorStateException。
-
await()会自动释放锁并挂起，被signal()唤醒后需重新竞争锁 - 必须用
while循环检查条件，而非if——因为存在虚假唤醒（spurious wakeup） - 一个
Lock可关联多个Condition，适合实现生产者-消费者中的“空”和“满”两种等待队列
ReentrantLock lock = new ReentrantLock();
Condition notEmpty = lock.newCondition();
Condition notFull = lock.newCondition();
// 消费者等待非空
lock.lock();
try {
while (queue.isEmpty()) {
notEmpty.await(); // 自动释放 lock
}
return queue.poll();
} finally {
lock.unlock();
}
锁升级、中断响应与可重入性陷阱
ReentrantLock 支持可重入（同一线程可多次 lock()）、响应中断（lockInterruptibly()）、尝试获取（tryLock()），但这些特性容易误用。
立即学习“Java免费学习笔记（深入）”；
- 每次
lock()都要对应一次unlock()，嵌套调用时计数不匹配会导致后续线程无法获取锁 -
lockInterruptibly()在等待锁时可被Thread.interrupt()中断，但已持锁后中断不影响锁状态 - 不要在持有锁期间调用可能阻塞的外部方法（如 I/O、远程调用），否则会拖长锁持有时间，放大争抢
-
getHoldCount()和getQueueLength()是诊断工具，但它们的返回值是近似值，不保证实时准确
真正难的不是写对语法，而是判断该不该用 ReentrantLock：多数场景 synchronized 更安全简洁；只有需要条件队列、超时获取、或精确控制锁行为时，才值得引入显式锁的复杂性。
