ReadWriteLock通过读共享、写独占机制提升读多写少场景下的并发性能，相比ReentrantLock能显著减少读操作的等待时间，提高吞吐量。
在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
。
总的来说，
ReadWriteLock是Java并发工具箱中一个非常强大的工具，尤其适用于读密集型场景。但就像所有强大的工具一样，它需要被正确理解和谨慎使用，才能发挥出最大的价值。
