ReentrantLock显式锁使用全解析

本文深入剖析了Java显式锁ReentrantLock的核心使用要点与常见陷阱：强调必须在finally块中手动调用unlock()以避免因异常、中断或提前返回导致的永久死锁；对比lock()与tryLock()在阻塞行为上的本质差异，指出超时控制和非阻塞获取的适用场景；警示公平锁虽保障等待顺序但显著牺牲性能，且公平性仅作用于队列内线程；详解Condition如何实现精准、多条件的线程协作，规避传统wait/notify的局限；最终点明关键原则——synchronized仍是多数场景的首选，ReentrantLock仅在需要尝试加锁、超时机制、多条件等待或特定公平策略时才真正必要。

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更可控。

• 一个ReentrantLock可绑定多个Condition，比如生产者用notFull，消费者用notEmpty，避免虚假唤醒干扰
• await()会自动释放锁并挂起线程；被signal()唤醒后，必须重新竞争锁，成功后才继续执行
• 别在synchronized块里调用Condition方法——会抛IllegalMonitorStateException，它只认自己关联的ReentrantLock

真正难的不是写对语法，而是判断该不该用ReentrantLock——多数简单同步场景，synchronized更安全、JIT优化更好；只有需要尝试获取、超时控制、多条件等待或公平性策略时，才值得引入显式锁。

理论要掌握，实操不能落！以上关于《ReentrantLock显式锁使用全解析》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！