Java中ReentrantLock的核心用法-java教程-PHP中文网

ReentrantLock通过lock()和unlock()方法实现手动加锁与释放，确保线程安全；其相比synchronized提供更灵活的锁控制，如可中断、超时获取、公平性选择及条件变量支持；使用时需在finally块中释放锁以避免死锁，推荐非公平锁提升性能，合理控制锁粒度，并利用Condition实现复杂线程协作。

java中reentrantlock的核心用法

ReentrantLock在Java并发编程中扮演着关键角色，它提供了一种可重入的互斥锁机制，功能上与

synchronized

登录后复制

关键字有相似之处，但在灵活性和功能性上往往更胜一筹。它的核心用法，说白了，就是通过

lock()

登录后复制

和

unlock()

登录后复制

这两个方法，来手动圈定并保护那些需要线程安全的代码区域。

ReentrantLock的核心用法，简单来说，就是围绕着

lock()

登录后复制

和

unlock()

登录后复制

这两个方法展开的。当你有一段代码，比如说更新一个共享变量，或者访问一个共享资源，你肯定不希望多个线程同时去搞乱它，对吧？这时候，你就在这段代码的入口处调用

lock()

登录后复制

方法，告诉系统：“嘿，我这块地盘要独占了！”然后，等你的操作完成，无论中间有没有出什么岔子，你都必须在

finally

登录后复制

块里调用

unlock()

登录后复制

方法，把这块地盘“还”回去。这样一来，其他等待的线程才能有机会进来。

import java.util.concurrent.locks.ReentrantLock;

public class SharedResource {
    private final ReentrantLock accessLock = new ReentrantLock();
    private int counter = 0;

    public void increment() {
        accessLock.lock(); // 尝试获取锁，如果锁被占用，当前线程会在这里等待
        try {
            // 这是临界区代码，只有获取到锁的线程才能执行
            counter++;
            System.out.println(Thread.currentThread().getName() + " incremented counter to: " + counter);
        } finally {
            accessLock.unlock(); // 确保锁在任何情况下都能被释放
        }
    }

    public int getCounter() {
        return counter;
    }

    public static void main(String[] args) throws InterruptedException {
        SharedResource resource = new SharedResource();

        Runnable task = () -> {
            for (int i = 0; i < 1000; i++) {
                resource.increment();
            }
        };

        Thread t1 = new Thread(task, "Worker-1");
        Thread t2 = new Thread(task, "Worker-2");

        t1.start();
        t2.start();

        t1.join(); // 等待线程t1执行完毕
        t2.join(); // 等待线程t2执行完毕

        System.out.println("Final counter value: " + resource.getCounter()); // 预期输出 2000
    }
}

登录后复制

你看，这个例子里

increment()

登录后复制

方法就是被保护的临界区。

accessLock.lock()

登录后复制

会阻塞当前线程，直到它成功拿到锁。而把

accessLock.unlock()

登录后复制

放在

finally

登录后复制

块里，这绝对是个“黄金法则”，它保证了即使在

try

登录后复制

块里代码抛出了异常，锁也一定会被释放，避免了死锁这种灾难性的后果。

ReentrantLock与synchronized有什么不同，我该如何选择？

这个问题啊，几乎每个Java开发者在接触并发编程时都会遇到。ReentrantLock和

synchronized

登录后复制

，它们都能实现互斥访问，确保线程安全，但它们之间确实存在一些设计哲学和功能上的差异。

立即学习“Java免费学习笔记（深入）”；

synchronized

登录后复制

是Java语言内置的关键字，用起来很省心，你只需要把它放在方法签名上或者用作代码块的修饰符，编译器就会自动帮你处理锁的获取和释放。它天生支持可重入性，而且在遇到异常时，也会自动释放锁。它的优点是简洁、不易出错，对于简单的同步需求，它通常是我的首选。但它的缺点也很明显，就是不够灵活。比如，你没法“问”一下锁是否可用（非阻塞地尝试获取），也没法给获取锁设置个超时时间，更别说中断一个正在苦苦等待锁的线程了。

ReentrantLock则是一个实实在在的类，你需要手动去实例化它，然后用

lock()

登录后复制

和

unlock()

登录后复制

方法来控制。它的优势在于提供了

synchronized

登录后复制

所不具备的更细粒度的控制和更丰富的功能：

可中断的锁获取（
lockInterruptibly()
登录后复制
）：这意味着一个正在等待锁的线程可以响应中断，而不是一直傻等下去。
尝试获取锁（
tryLock()
登录后复制
）：这个方法非常有用，它会非阻塞地尝试获取锁。如果获取成功就返回
```
true
```
登录后复制
，失败就立即返回
```
false
```
登录后复制
，线程可以继续做其他事情，避免了死等。
超时获取锁（
tryLock(long timeout, TimeUnit unit)
登录后复制
）：在指定的时间内尝试获取锁，如果超时还没拿到，就放弃。这对于避免死锁或者提高系统的响应性很有帮助。
公平锁选项（
ReentrantLock(boolean fair)
登录后复制
）：你可以选择创建一个公平锁，让等待时间最长的线程优先获取锁，避免“插队”现象，但通常会牺牲一点性能。
条件变量（
newCondition()
登录后复制
）：这是ReentrantLock一个非常强大的特性，它提供了比
```
Object
```
登录后复制
的
```
wait()/notify()
```
登录后复制
更灵活的线程间协作机制。你可以在同一个锁上定义多个条件变量，实现更精细的等待/通知。

所以，我的选择策略通常是这样的：如果只是简单的互斥访问，且对性能没有极致要求，

synchronized

登录后复制

因为其简洁性，通常是更好的选择。但如果我需要更高级的并发控制，比如需要非阻塞地获取锁、设置超时、或者需要条件变量进行复杂的线程间通信，那么ReentrantLock就显得不可或缺了。在一些复杂的并发框架或库中，ReentrantLock及其配套工具（如Condition）的应用更为广泛。

ReentrantLock的公平性与非公平性，我应该用哪种？

ReentrantLock在构造时可以传入一个布尔值参数来决定它是公平锁还是非公平锁。如果你不传这个参数，它默认会创建一个非公平锁。这两种模式，各有各的特点，选择哪种，得看你的具体需求和对性能的权衡。

百度文心百中

百度大模型语义搜索体验中心

查看详情

非公平锁（Nonfair Lock）：这是ReentrantLock的默认行为。当一个线程请求锁时，如果锁当前是可用的，它会直接尝试去获取，而不会去管是否有其他线程已经在等待队列里排队了。这有点像“谁手快谁就可能抢到”的模式。非公平锁的优点在于它的性能通常比公平锁要高，因为它减少了线程上下文切换和排队管理的开销。在大多数情况下，非公平锁是更好的选择，因为它能提供更高的吞吐量。它的缺点是，理论上可能会导致“饥饿”现象，就是某些等待时间较长的线程可能一直获取不到锁，虽然在实际高并发场景中，这种极端情况并不那么常见。
公平锁（Fair Lock）：当一个线程请求锁时，如果锁当前被持有，它会老老实实地进入等待队列，并且只有当它是队列中的第一个线程时，才能获取锁。这就像是“排队取号”的模式，先来后到，非常讲究秩序。公平锁的优点是它能够避免饥饿现象，保证所有等待线程最终都能获取到锁。但它的缺点是性能开销相对较大，因为每次获取锁都需要检查等待队列，这会增加线程切换和调度器的负担。

我的建议是，除非你对公平性有非常严格的业务要求，比如在某些资源调度或优先级分配的场景中，否则通常应该优先选择非公平锁。在绝大多数业务应用中，性能往往是更重要的考量因素，而非公平锁在吞吐量上表现得更好。而且，非公平锁带来的饥饿问题在实际应用中，往往可以通过良好的并发模型设计来缓解，或者其影响程度并不至于无法接受。如果你真的非常担心饥饿，可能需要重新审视你的并发模型，或者考虑更高级的无锁（Lock-Free）数据结构。

使用ReentrantLock时有哪些常见的陷阱和最佳实践？

ReentrantLock虽然功能强大，给我们提供了很多

synchronized

登录后复制

不具备的灵活性，但这种手动管理锁的模式也意味着更高的出错风险。

常见的陷阱：

忘记释放锁（
unlock()
登录后复制
）：这绝对是使用ReentrantLock时最常见也最致命的错误。如果在
```
try
```
登录后复制
块中获取锁后，没有在
```
finally
```
登录后复制
块中调用
```
unlock()
```
登录后复制
释放锁，一旦
```
try
```
登录后复制
块中的代码抛出异常，那么这个锁就永远不会被释放了。结果就是，其他所有等待该锁的线程将永远阻塞，整个系统就陷入了死锁状态。
在不持有锁的情况下释放锁：ReentrantLock是可重入的，但如果你在没有获取锁，或者获取次数少于释放次数的情况下调用
```
unlock()
```
登录后复制
，它会抛出
```
IllegalMonitorStateException
```
登录后复制
。虽然这通常不会导致死锁，但仍然是一个运行时错误。
锁的粒度不当：如果锁的保护范围太大（粒度过粗），会降低并发度，导致很多不必要的等待；如果锁的保护范围太小（粒度过细），又可能导致过多的锁竞争和上下文切换开销，甚至引入新的并发问题。
死锁：当多个线程互相等待对方释放锁时，就会发生死锁。这通常发生在涉及多个锁的复杂场景中。比如，线程A持有锁1，想获取锁2；同时线程B持有锁2，想获取锁1。
不加区分地使用公平锁：前面也提到了，公平锁通常性能较差。如果你的应用对公平性没有强烈的要求，却使用了公平锁，那很可能是在不经意间牺牲了性能。

最佳实践：

始终在
finally
登录后复制
块中释放锁：这是使用ReentrantLock的黄金法则，它能确保无论
```
try
```
登录后复制
块中的代码是否抛出异常，锁都能被正确释放。
```
myLock.lock();
try {
    // 你的临界区代码
} finally {
    myLock.unlock();
}
```
登录后复制
避免在持有锁时执行耗时操作或I/O操作：如果一个线程在持有锁的情况下执行了很长时间的操作，特别是I/O操作（比如网络请求、文件读写），会长时间阻塞其他等待线程，严重影响并发性能。如果确实需要，考虑将这些操作移到锁之外，或者使用更细粒度的锁来保护不同的资源。
合理选择锁的粒度：根据业务逻辑和性能需求，仔细设计锁的保护范围。通常，只保护真正需要同步的共享资源，而不是整个方法或一大段代码。
警惕死锁：在设计涉及多个锁的并发逻辑时，要特别小心。可以尝试遵循一些死锁预防策略，比如：
- 固定锁的获取顺序：所有线程都按照相同的顺序获取多个锁。
- 使用
  tryLock()
  登录后复制
  带超时：避免无限等待，一旦超时未获取到锁就放弃，并回滚已获取的锁。
- 避免嵌套锁：尽量减少在一个锁内部获取另一个锁的情况。
优先使用非公平锁：除非有明确的公平性需求，否则默认使用非公平锁以获得更好的性能。
充分利用
Condition
登录后复制
进行线程协作：当需要实现生产者-消费者模式或者其他复杂的等待/通知机制时，ReentrantLock的
```
newCondition()
```
登录后复制
方法提供的条件变量是比
```
Object
```
登录后复制
的
```
wait()/notify()
```
登录后复制
更强大的工具。它能让你在同一个锁上定义多个等待队列，从而实现更精细、更灵活的线程间通信。