Java锁机制与ReentrantLock使用全解析

你在学习文章相关的知识吗？本文《Java锁机制详解与ReentrantLock使用教程》，主要介绍的内容就涉及到，如果你想提升自己的开发能力，就不要错过这篇文章，大家要知道编程理论基础和实战操作都是不可或缺的哦！

多数场景优先用 synchronized；仅当需 tryLock、可中断等待、公平锁或多个 Condition 时才选 ReentrantLock，且必须手动在 finally 中 unlock，否则易死锁。

ReentrantLock 和 synchronized 到底该选谁

多数场景下，synchronized 足够用，且更安全；只有当你需要 tryLock()、可中断等待、公平锁或绑定多个 Condition 时，才值得换成 ReentrantLock。别为了“看起来高级”而替换——它不自动释放锁，写错就死锁。

ReentrantLock 必须手动 unlock() 的坑

忘记在 finally 块中调用 unlock() 是最常见错误，会导致锁永远无法释放，后续线程全部阻塞。Java 不会像 synchronized 那样在作用域退出时自动清理。

• 必须把 lock() 放在 try 外面，unlock() 放在 finally 里
• 不能在构造函数或异常未捕获的分支中提前 return，否则 finally 不执行
• 如果用在循环里，每次迭代都要独立完成 lock/unlock，不能跨迭代复用

ReentrantLock lock = new ReentrantLock();
lock.lock();
try {
    // 业务逻辑
} finally {
    lock.unlock(); // 这行绝不能少，也不能写在 try 或 catch 里
}

公平锁参数 true 的代价很大

创建 ReentrantLock 时传 true 启用公平模式（new ReentrantLock(true)），会让线程按请求顺序排队，但吞吐量通常下降 2–5 倍。JVM 默认的非公平模式（false 或无参构造）允许插队，反而更高效。

• 公平锁只在极少数对响应时间敏感、且能容忍低吞吐的场景有用（如实时任务调度）
• 高并发 Web 服务、数据处理流水线一律用默认非公平模式
• isFair() 返回 true 并不表示当前没线程在等，只是说明构造时设了公平参数

Condition 替代 wait/notify 时的线程唤醒控制

ReentrantLock 配合 Condition 可以实现比 Object.wait() 更精细的唤醒策略，比如只唤醒“等待读”的线程，而不惊动“等待写”的线程。

• 一个 ReentrantLock 可创建多个 Condition 实例，各自维护独立等待队列
• condition.signal() 不保证唤醒哪个线程，signalAll() 才全唤醒
• 必须在持有锁的前提下调用 await()，否则抛 IllegalMonitorStateException
• 和 wait() 一样，await() 会释放锁，并在被唤醒后重新竞争锁

ReentrantLock lock = new ReentrantLock();
Condition notFull = lock.newCondition();
Condition notEmpty = lock.newCondition();

lock.lock();
try {
    while (queue.size() == MAX_SIZE) {
        notFull.await(); // 释放锁，进入 notFull 等待队列
    }
    queue.add(item);
    notEmpty.signal(); // 只唤醒一个等待消费的线程
} finally {
    lock.unlock();
}

用 ReentrantLock 最容易忽略的不是语法，而是锁的生命周期管理——它不像 synchronized 那样“进块即加，出块即放”，你得自己盯住每一对 lock()/unlock()，尤其是在有多个 return 路径、嵌套 try 或带异常重试的逻辑里。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。