如何使用ReentrantLock显式锁替代同步块实现灵活加锁

林译川

2026-10-19 • 👁 0人浏览过

ReentrantLock 可实现 tryLock、限时等待、响应中断和灵活释放锁，而 synchronized 不支持；必须用 try-finally 确保 unlock() 执行，且仅在 lock() 成功后调用；公平锁降低吞吐量，应按需选用。为什么不能直接用

synchronized

就得换

ReentrantLock

当需要尝试获取锁（不阻塞）、限时等待锁、响应中断、或按需释放锁顺序时，

synchronized

无能为力。

ReentrantLock

提供了这些能力，但代价是必须显式

lock()

和

unlock()

，漏掉

unlock()

就会死锁。典型场景包括：避免线程无限等待（如远程调用超时前放弃抢锁）、实现公平调度、或在

try

块中做多步操作后统一判断是否要释放锁。

lock()

必须配对

unlock()

，且只能在

finally

块里写这是最容易翻车的地方。写在

try

或

catch

里，一旦抛异常就跳过

unlock()

；写在

if

分支里，路径一多就漏。正确写法：始终把

unlock()

放在

finally

块中，且确保

lock()

成功后才进

finally

错误写法：

lock()

后直接跟

unlock()

（没进

try-finally

），或把

unlock()

放在

catch

里注意：不能在

lock()

失败时调用

unlock()

，会抛

IllegalMonitorStateException

ReentrantLock lock = new ReentrantLock();
lock.lock(); // 成功才继续
try {
    // 临界区操作
} finally {
    lock.unlock(); // 这里必须执行，且只在 lock() 成功后才可能到达
}

用

tryLock()

实现非阻塞或限时抢锁

tryLock()

不会挂起线程，适合高并发下“抢不到就走”的策略；

tryLock(long, TimeUnit)

则可用于设置最大等待时间，避免卡死。返回

false

表示当前未获得锁，不是异常，不要当成错误处理如果用了带超时的

tryLock()

，超时后线程不会被中断，但可配合

Thread.interrupted()

做协作取消注意：超时单位必须用

TimeUnit

，传整数毫秒会编译失败（方法重载不匹配）

if (lock.tryLock(100, TimeUnit.MILLISECONDS)) {
    try {
        // 拿到锁，执行业务
    } finally {
        lock.unlock();
    }
} else {
    // 抢锁失败，走降级逻辑（如返回缓存、抛限流异常）
}

公平锁与性能开销：别盲目设

true

new ReentrantLock(true)

开启公平模式后，线程按 FIFO 排队，避免饥饿，但吞吐量通常下降 20%~50%，因为每次都要检查队列头。默认非公平锁更高效，适用于大多数场景（JVM 的

synchronized

也是非公平的）只有明确遇到低优先级线程长期抢不到锁、且压测证实不公平导致问题时，才考虑公平锁公平锁无法解决“锁粒度不合理”或“临界区过长”这类根本问题，加了也白加真正难的是锁范围控制——比如该锁对象 A 却锁了整个类，或该分段锁却用了单个

ReentrantLock

。这种设计偏差，比选公平还是非公平影响大得多。

相关文章