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 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 store.readData(), "Reader-" + i).start(); } }}
这段代码展示了
ReadWriteLock
的基本用法。读操作通过
readLock
保护，允许多个线程同时进入；写操作通过
writeLock
保护，一次只允许一个线程进入，并且在写锁被持有时，任何读锁都无法获取。
立即学习“Java免费学习笔记（深入）”；
为什么在Java并发场景下，我们更倾向于使用ReadWriteLock而非ReentrantLock？
这个问题，在我看来，核心在于“效率”和“场景匹配度”。当我们在处理并发数据时，最常见的锁是
ReentrantLock
，它简单直接，就像一个排他性的门禁：一次只允许一个人通过，无论是进去看还是进去改。这在很多情况下是没问题的，因为它保证了数据的一致性。
然而，现实世界的数据访问模式往往是“读多写少”。比如一个配置中心，配置一旦加载，大部分时间都是被读取，只有偶尔才会被更新。如果这时我们还用
ReentrantLock
，那么即使是两个线程只是想同时读取同一个配置，它们也必须排队，一个读完另一个才能读。这显然是一种资源浪费，因为读操作本身并不会改变数据，所以多个读操作同时进行是安全的。
ReadWriteLock
的出现，就是为了解决这种不必要的排队。它提供了一种更细粒度的控制：
读共享，写独占： 允许多个读线程同时访问资源，极大地提升了并发性能。写独占，读写互斥： 当有写线程在工作时，所有读线程和写线程都必须等待，确保数据在修改过程中的一致性。
所以，如果你的应用场景是读操作远超写操作，那么
ReadWriteLock
就能显著提升系统的吞吐量和响应速度。如果读写操作的比例差不多，或者写操作非常频繁，那么
ReentrantLock
或者甚至
synchronized
可能更简单高效，因为
ReadWriteLock
本身的实现会比简单的排他锁复杂一些，有额外的开销。选择哪个，真的要看你的数据访问模式。
ReadWriteLock的读写锁升级与降级机制是如何工作的？
谈到
ReadWriteLock
，就不得不提它的锁升级和降级，这有点像我们处理事务时的灵活变通。
锁升级（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并发工具箱中一个非常强大的工具，尤其适用于读密集型场景。但就像所有强大的工具一样，它需要被正确理解和谨慎使用，才能发挥出最大的价值。
以上就是如何在Java中使用Read Write Lock的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/75342.html
微信扫一扫 
支付宝扫一扫 
