如何在Java中使用Read Write Lock-java教程-PHP中文网

ReadWriteLock通过读共享、写独占机制提升读多写少场景下的并发性能，相比ReentrantLock能显著减少读操作的等待时间，提高吞吐量。

如何在java中使用read write lock

在Java中，使用

ReadWriteLock

登录后复制

主要是为了解决并发场景下，读操作远多于写操作时，

synchronized

登录后复制

或

ReentrantLock

登录后复制

的性能瓶颈。它的核心思想是：允许多个线程同时读取共享资源，但只允许一个线程进行写入操作，并且在写入时，任何读写操作都必须等待。这就像图书馆里，大家可以同时看书（读），但只有管理员可以整理书架（写），且管理员整理时，其他人不能动书。

解决方案

在Java中，

java.util.concurrent.locks.ReentrantReadWriteLock

登录后复制

是

ReadWriteLock

登录后复制

接口的一个实现。要使用它，你需要创建一个

ReentrantReadWriteLock

登录后复制

实例，然后通过它的

readLock()

登录后复制

和

writeLock()

登录后复制

方法获取对应的读锁和写锁。

基本的模式是这样的：

import java.util.concurrent.locks.ReentrantReadWriteLock;
import java.util.concurrent.locks.Lock;

public class DataStore {
    private final ReentrantReadWriteLock rwLock = new ReentrantReadWriteLock();
    private final Lock readLock = rwLock.readLock();
    private final Lock writeLock = rwLock.writeLock();

    private String data = "Initial Data";

    public String readData() {
        readLock.lock(); // 获取读锁
        try {
            // 模拟读取操作
            System.out.println(Thread.currentThread().getName() + " is reading data: " + data);
            Thread.sleep(50); // 模拟耗时
            return data;
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
            return null;
        } finally {
            readLock.unlock(); // 释放读锁
        }
    }

    public void writeData(String newData) {
        writeLock.lock(); // 获取写锁
        try {
            // 模拟写入操作
            System.out.println(Thread.currentThread().getName() + " is writing data: " + newData);
            this.data = newData;
            Thread.sleep(100); // 模拟耗时
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        } finally {
            writeLock.unlock(); // 释放写锁
        }
    }

    public static void main(String[] args) {
        DataStore store = new DataStore();

        // 启动多个读取线程
        for (int i = 0; i < 5; i++) {
            new Thread(() -> store.readData(), "Reader-" + i).start();
        }

        // 启动一个写入线程
        new Thread(() -> store.writeData("New Data 1"), "Writer-1").start();
        new Thread(() -> store.writeData("New Data 2"), "Writer-2").start();

        // 再次启动读取线程，观察写入后的数据
        try {
            Thread.sleep(500); // 等待一些操作完成
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
        for (int i = 5; i < 10; i++) {
            new Thread(() -> store.readData(), "Reader-" + i).start();
        }
    }
}

登录后复制

这段代码展示了

ReadWriteLock

登录后复制

的基本用法。读操作通过

readLock

登录后复制

保护，允许多个线程同时进入；写操作通过

writeLock

登录后复制

保护，一次只允许一个线程进入，并且在写锁被持有时，任何读锁都无法获取。

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

为什么在Java并发场景下，我们更倾向于使用ReadWriteLock而非ReentrantLock？

这个问题，在我看来，核心在于“效率”和“场景匹配度”。当我们在处理并发数据时，最常见的锁是

ReentrantLock

登录后复制

，它简单直接，就像一个排他性的门禁：一次只允许一个人通过，无论是进去看还是进去改。这在很多情况下是没问题的，因为它保证了数据的一致性。

然而，现实世界的数据访问模式往往是“读多写少”。比如一个配置中心，配置一旦加载，大部分时间都是被读取，只有偶尔才会被更新。如果这时我们还用

ReentrantLock

登录后复制

，那么即使是两个线程只是想同时读取同一个配置，它们也必须排队，一个读完另一个才能读。这显然是一种资源浪费，因为读操作本身并不会改变数据，所以多个读操作同时进行是安全的。

ReadWriteLock

登录后复制

的出现，就是为了解决这种不必要的排队。它提供了一种更细粒度的控制：

读共享，写独占： 允许多个读线程同时访问资源，极大地提升了并发性能。
写独占，读写互斥： 当有写线程在工作时，所有读线程和写线程都必须等待，确保数据在修改过程中的一致性。

所以，如果你的应用场景是读操作远超写操作，那么

ReadWriteLock

登录后复制

就能显著提升系统的吞吐量和响应速度。如果读写操作的比例差不多，或者写操作非常频繁，那么

ReentrantLock

登录后复制

或者甚至

synchronized

登录后复制

可能更简单高效，因为

ReadWriteLock

登录后复制

本身的实现会比简单的排他锁复杂一些，有额外的开销。选择哪个，真的要看你的数据访问模式。

ReadWriteLock的读写锁升级与降级机制是如何工作的？

谈到

ReadWriteLock

登录后复制

，就不得不提它的锁升级和降级，这有点像我们处理事务时的灵活变通。

Android 开发者指南第一部分：入门

Android文档-开发者指南-第一部分：入门-中英文对照版 Android提供了丰富的应用程序框架，它允许您在Java语言环境中构建移动设备的创新应用程序和游戏。在左侧导航中列出的文档提供了有关如何使用Android的各种API来构建应用程序的详细信息。第一部分：Introduction(入门) 0、Introduction to Android(引进到Android) 1、Application Fundamentals(应用程序基础) 2、Device Compatibility(设备兼容性) 3、

查看详情

锁升级（Read-to-Write Upgrade）： 这个概念听起来很诱人：我先拿着读锁，发现需要修改数据了，就直接把读锁“升级”成写锁。但遗憾的是，

ReentrantReadWriteLock

登录后复制

不支持 这种直接的读锁升级。为什么呢？设想一下，如果A线程持有读锁，B线程也持有读锁。A想升级成写锁，它会尝试获取写锁。但由于B线程还持有读锁，A会被阻塞。如果B线程也想升级成写锁，它也会被阻塞。这样就形成了一个经典的死锁。为了避免这种潜在的死锁风险，

ReentrantReadWriteLock

登录后复制

的设计者们选择不支持读锁直接升级。如果你真的需要在持有读锁后修改数据，正确的做法是：先释放读锁，然后尝试获取写锁。 这意味着在释放读锁到获取写锁之间，数据可能会被其他线程修改，所以你需要重新检查或处理数据的一致性。

锁降级（Write-to-Read Downgrade）： 与升级相反，锁降级是支持的，而且在某些场景下非常有用。它的流程是：

一个线程获取了写锁。
在持有写锁的情况下，该线程再获取读锁。
然后，该线程释放写锁。此时，该线程仍然持有读锁。

这个机制有什么用呢？想象一下，你修改了一段数据，现在想在允许其他线程读取的同时，自己也需要继续读取这个最新修改的数据，并且确保这段时间没有其他线程来修改它。通过降级，你可以在释放写锁后，立即让其他读者进来，而你自己的线程仍然可以安全地读取，因为你还持有读锁。这样既保证了修改后的数据立即可读，又避免了在读操作时再次排队等待。

public void processAndReadData(String newData) {
    writeLock.lock(); // 1. 获取写锁
    try {
        System.out.println(Thread.currentThread().getName() + " is writing and then downgrading.");
        this.data = newData; // 修改数据

        // 2. 在持有写锁的同时，获取读锁
        readLock.lock(); 
        System.out.println(Thread.currentThread().getName() + " acquired read lock.");
    } finally {
        writeLock.unlock(); // 3. 释放写锁
        System.out.println(Thread.currentThread().getName() + " released write lock.");
    }

    // 此时线程仍然持有读锁，可以安全地读取
    try {
        System.out.println(Thread.currentThread().getName() + " is reading data after downgrade: " + data);
        Thread.sleep(50);
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
    } finally {
        readLock.unlock(); // 4. 最终释放读锁
        System.out.println(Thread.currentThread().getName() + " released read lock.");
    }
}

登录后复制

锁降级是一个非常实用的模式，它允许我们在完成关键的写操作后，立即切换到读模式，从而减少写锁的持有时间，提高并发性。

使用ReadWriteLock时，有哪些常见的陷阱或性能考量需要注意？

ReadWriteLock

登录后复制

虽然强大，但使用起来并非没有坑。在我实际开发中，有几个点是需要特别留意的：

公平性与吞吐量：
```
ReentrantReadWriteLock
```
登录后复制
可以配置为公平锁（
```
new ReentrantReadWriteLock(true)
```
登录后复制
）或非公平锁（默认）。
- 非公平锁 倾向于更高的吞吐量，因为它允许“插队”。新来的读线程或写线程可能直接获取锁，而不管是否有其他线程等待。这可能导致写线程饥饿：如果一直有读线程不断地获取和释放读锁，写线程可能永远无法获得写锁。
```
ReentrantReadWriteLock
```
  登录后复制
  默认是非公平的，但它在实现上对写线程有一定的偏向，即当一个写线程等待时，新的读请求可能会被阻塞，给写线程一个机会。
- 公平锁 保证了线程获取锁的顺序与它们请求锁的顺序一致。这可以避免饥饿，但通常会带来额外的性能开销。在大多数高性能场景下，非公平锁是首选，但如果你的应用对公平性有严格要求，或者遇到了写线程饥饿的问题，可以考虑公平锁。
锁的粒度： 这是一个老生常谈的问题，但在
```
ReadWriteLock
```
登录后复制
这里尤为重要。
- 锁粒度过粗： 如果你把整个大型数据结构都用一个
```
ReadWriteLock
```
  登录后复制
  保护起来，那么即使是两个不相关的部分，一个读一个写，也可能互相阻塞，这会大大降低
```
ReadWriteLock
```
  登录后复制
  带来的并发优势。
- 锁粒度过细： 如果你尝试为数据结构的每一个小元素都设置一个
```
ReadWriteLock
```
  登录后复制
  ，那么锁本身的开销（内存占用、上下文切换等）可能会抵消并发带来的好处，甚至让性能更差。选择合适的粒度需要仔细分析数据结构和访问模式。有时，分段锁（如
```
ConcurrentHashMap
```
  登录后复制
  ）可能是更好的选择。
死锁风险： 虽然
```
ReadWriteLock
```
登录后复制
本身在设计上避免了读锁升级导致的死锁，但如果你的代码逻辑复杂，或者涉及多个
```
ReadWriteLock
```
登录后复制
，仍然可能出现死锁。例如，如果线程A持有
```
lock1
```
登录后复制
的写锁，并尝试获取
```
lock2
```
登录后复制
的写锁；同时线程B持有
```
lock2
```
登录后复制
的写锁，并尝试获取
```
lock1
```
登录后复制
的写锁，这就形成了经典的死锁。始终要警惕多锁场景下的获取顺序。
过度优化： 别忘了，
```
ReadWriteLock
```
登录后复制
的实现比
```
ReentrantLock
```
登录后复制
或
```
synchronized
```
登录后复制
更复杂，这意味着它有更高的内部开销。如果你的临界区代码执行速度非常快，或者读写比例并没有那么悬殊，那么引入
```
ReadWriteLock
```
登录后复制
可能并不能带来预期的性能提升，反而可能因为其自身的复杂性而导致性能下降。在引入任何复杂的并发机制之前，性能分析（Profiling） 总是最好的朋友。先用简单的锁，如果发现瓶颈确实在读写竞争上，再考虑
```
ReadWriteLock
```
登录后复制
。