登录
首页 >  文章 >  java教程

ReentrantLock线程控制全解析

时间:2026-01-23 14:09:39 406浏览 收藏

哈喽!今天心血来潮给大家带来了《Java中ReentrantLock线程控制详解》,想必大家应该对文章都不陌生吧,那么阅读本文就都不会很困难,以下内容主要涉及到,若是你正在学习文章,千万别错过这篇文章~希望能帮助到你!

ReentrantLock需手动配对acquire/release,必须用try-finally确保unlock;默认非公平锁性能更优;Condition替代wait/notify须用while重检条件;仅在需超时、中断响应或多个条件队列时选用。

在Java里如何使用ReentrantLock控制线程同步_Java显式锁线程控制说明

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()),但这些特性容易误用。

  • 每次 lock() 都要对应一次 unlock(),嵌套调用时计数不匹配会导致后续线程无法获取锁
  • lockInterruptibly() 在等待锁时可被 Thread.interrupt() 中断,但已持锁后中断不影响锁状态
  • 不要在持有锁期间调用可能阻塞的外部方法(如 I/O、远程调用),否则会拖长锁持有时间,放大争抢
  • getHoldCount()getQueueLength() 是诊断工具,但它们的返回值是近似值,不保证实时准确

真正难的不是写对语法,而是判断该不该用 ReentrantLock:多数场景 synchronized 更安全简洁;只有需要条件队列、超时获取、或精确控制锁行为时,才值得引入显式锁的复杂性。

今天关于《ReentrantLock线程控制全解析》的内容就介绍到这里了,是不是学起来一目了然!想要了解更多关于的内容请关注golang学习网公众号!

前往漫画官网入口并下载 ➜
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>