原文链接 作者:Jakob Jenkov 译者:微凉 校对:丁一
相比Java中的锁(Locks in Java)里Lock实现,读写锁更复杂一些。假设你的程序中涉及到对一些共享资源的读和写操作,且写操作没有读操作那么频繁。在没有写操作的时候,两个线程同时读一个资源没有任何问题,所以应该允许多个线程能在同时读取共享资源。但是如果有一个线程想去写这些共享资源,就不应该再有其它线程对该资源进行读或写(译者注:也就是说:读-读能共存,读-写不能共存,写-写不能共存)。这就需要一个读/写锁来解决这个问题。
Java5在java.util.concurrent包中已经包含了读写锁。尽管如此,我们还是应该了解其实现背后的原理。
以下是本文的主题
- 读/写锁的Java实现(Read / Write Lock Java Implementation)
- 读/写锁的重入(Read / Write Lock Reentrance)
- 读锁重入(Read Reentrance)
- 写锁重入(Write Reentrance)
- 读锁升级到写锁(Read to Write Reentrance)
- 写锁降级到读锁(Write to Read Reentrance)
- 可重入的ReadWriteLock的完整实现(Fully Reentrant ReadWriteLock)
- 在finally中调用unlock() (Calling unlock() from a finally-clause)
读/写锁的Java实现
先让我们对读写访问资源的条件做个概述:
读取 没有线程正在做写操作,且没有线程在请求写操作。
写入 没有线程正在做读写操作。
如果某个线程想要读取资源,只要没有线程正在对该资源进行写操作且没有线程请求对该资源的写操作即可。我们假设对写操作的请求比对读操作的请求更重要,就要提升写请求的优先级。此外,如果读操作发生的比较频繁,我们又没有提升写操作的优先级,那么就会产生“饥饿”现象。请求写操作的线程会一直阻塞,直到所有的读线程都从ReadWriteLock上解锁了。如果一直保证新线程的读操作权限,那么等待写操作的线程就会一直阻塞下去,结果就是发生“饥饿”。因此,只有当没有线程正在锁住ReadWriteLock进行写操作,且没有线程请求该锁准备执行写操作时,才能保证读操作继续。
当其它线程没有对共享资源进行读操作或者写操作时,某个线程就有可能获得该共享资源的写锁,进而对共享资源进行写操作。有多少线程请求了写锁以及以何种顺序请求写锁并不重要,除非你想保证写锁请求的公平性。
按照上面的叙述,简单的实现出一个读/写锁,代码如下
01 |
public class ReadWriteLock{
|
02 |
private int readers = 0 ;
|
03 |
private int writers = 0 ;
|
04 |
private int writeRequests = 0 ;
|
06 |
public synchronized void lockRead()
|
07 |
throws InterruptedException{
|
08 |
while (writers > 0 || writeRequests > 0 ){
|
14 |
public synchronized void unlockRead(){
|
19 |
public synchronized void lockWrite()
|
20 |
throws InterruptedException{
|
23 |
while (readers > 0 || writers > 0 ){
|
30 |
public synchronized void unlockWrite()
|
31 |
throws InterruptedException{
|
ReadWriteLock类中,读锁和写锁各有一个获取锁和释放锁的方法。
读锁的实现在lockRead()中,只要没有线程拥有写锁(writers==0),且没有线程在请求写锁(writeRequests ==0),所有想获得读锁的线程都能成功获取。
写锁的实现在lockWrite()中,当一个线程想获得写锁的时候,首先会把写锁请求数加1(writeRequests++),然后再去判断是否能够真能获得写锁,当没有线程持有读锁(readers==0 ),且没有线程持有写锁(writers==0)时就能获得写锁。有多少线程在请求写锁并无关系。
需要注意的是,在两个释放锁的方法(unlockRead,unlockWrite)中,都调用了notifyAll方法,而不是notify。要解释这个原因,我们可以想象下面一种情形:
如果有线程在等待获取读锁,同时又有线程在等待获取写锁。如果这时其中一个等待读锁的线程被notify方法唤醒,但因为此时仍有请求写锁的线程存在(writeRequests>0),所以被唤醒的线程会再次进入阻塞状态。然而,等待写锁的线程一个也没被唤醒,就像什么也没发生过一样(译者注:信号丢失现象)。如果用的是notifyAll方法,所有的线程都会被唤醒,然后判断能否获得其请求的锁。
用notifyAll还有一个好处。如果有多个读线程在等待读锁且没有线程在等待写锁时,调用unlockWrite()后,所有等待读锁的线程都能立马成功获取读锁 —— 而不是一次只允许一个。
读/写锁的重入
上面实现的读/写锁(ReadWriteLock) 是不可重入的,当一个已经持有写锁的线程再次请求写锁时,就会被阻塞。原因是已经有一个写线程了——就是它自己。此外,考虑下面的例子:
- Thread 1 获得了读锁
- Thread 2 请求写锁,但因为Thread 1 持有了读锁,所以写锁请求被阻塞。
- Thread 1 再想请求一次读锁,但因为Thread 2处于请求写锁的状态,所以想再次获取读锁也会被阻塞。
上面这种情形使用前面的ReadWriteLock就会被锁定——一种类似于死锁的情形。不会再有线程能够成功获取读锁或写锁了。
为了让ReadWriteLock可重入,需要对它做一些改进。下面会分别处理读锁的重入和写锁的重入。
读锁重入
为了让ReadWriteLock的读锁可重入,我们要先为读锁重入建立规则:
- 要保证某个线程中的读锁可重入,要么满足获取读锁的条件(没有写或写请求),要么已经持有读锁(不管是否有写请求)。
要确定一个线程是否已经持有读锁,可以用一个map来存储已经持有读锁的线程以及对应线程获取读锁的次数,当需要判断某个线程能否获得读锁时,就利用map中存储的数据进行判断。下面是方法lockRead和unlockRead修改后的的代码:
01 |
public class ReadWriteLock{
|
02 |
private Map<Thread, Integer> readingThreads =
|
03 |
new HashMap<Thread, Integer>();
|
05 |
private int writers = 0 ;
|
06 |
private int writeRequests = 0 ;
|
08 |
public synchronized void lockRead()
|
09 |
throws InterruptedException{
|
10 |
Thread callingThread = Thread.currentThread();
|
11 |
while (! canGrantReadAccess(callingThread)){
|
15 |
readingThreads.put(callingThread,
|
16 |
(getAccessCount(callingThread) + 1 ));
|
19 |
public synchronized void unlockRead(){
|
20 |
Thread callingThread = Thread.currentThread();
|
21 |
int accessCount = getAccessCount(callingThread);
|
22 |
if (accessCount == 1 ) {
|
23 |
readingThreads.remove(callingThread);
|
25 |
readingThreads.put(callingThread, (accessCount - 1 ));
|
30 |
private boolean canGrantReadAccess(Thread callingThread){
|
31 |
if (writers > 0 ) return false ;
|
32 |
if (isReader(callingThread) return true ;
|
33 |
if (writeRequests > 0 ) return false ;
|
37 |
private int getReadAccessCount(Thread callingThread){
|
38 |
Integer accessCount = readingThreads.get(callingThread);
|
39 |
if (accessCount == null ) return 0 ;
|
40 |
return accessCount.intValue();
|
43 |
private boolean isReader(Thread callingThread){
|
44 |
return readingThreads.get(callingThread) != null ;
|
代码中我们可以看到,只有在没有线程拥有写锁的情况下才允许读锁的重入。此外,重入的读锁比写锁优先级高。
写锁重入
仅当一个线程已经持有写锁,才允许写锁重入(再次获得写锁)。下面是方法lockWrite和unlockWrite修改后的的代码。
01 |
public class ReadWriteLock{
|
02 |
private Map<Thread, Integer> readingThreads =
|
03 |
new HashMap<Thread, Integer>();
|
05 |
private int writeAccesses = 0 ;
|
06 |
private int writeRequests = 0 ;
|
07 |
private Thread writingThread = null ;
|
09 |
public synchronized void lockWrite()
|
10 |
throws InterruptedException{
|
12 |
Thread callingThread = Thread.currentThread();
|
13 |
while (!canGrantWriteAccess(callingThread)){
|
18 |
writingThread = callingThread;
|
21 |
public synchronized void unlockWrite()
|
22 |
throws InterruptedException{
|
24 |
if (writeAccesses == 0 ){
|
30 |
private boolean canGrantWriteAccess(Thread callingThread){
|
31 |
if (hasReaders()) return false ;
|
32 |
if (writingThread == null ) return true ;
|
33 |
if (!isWriter(callingThread)) return false ;
|
37 |
private boolean hasReaders(){
|
38 |
return readingThreads.size() > 0 ;
|
41 |
private boolean isWriter(Thread callingThread){
|
42 |
return writingThread == callingThread;
|
注意在确定当前线程是否能够获取写锁的时候,是如何处理的。
读锁升级到写锁
有时,我们希望一个拥有读锁的线程,也能获得写锁。想要允许这样的操作,要求这个线程是唯一一个拥有读锁的线程。writeLock()需要做点改动来达到这个目的:
01 |
public class ReadWriteLock{
|
02 |
private Map<Thread, Integer> readingThreads =
|
03 |
new HashMap<Thread, Integer>();
|
05 |
private int writeAccesses = 0 ;
|
06 |
private int writeRequests = 0 ;
|
07 |
private Thread writingThread = null ;
|
09 |
public synchronized void lockWrite()
|
10 |
throws InterruptedException{
|
12 |
Thread callingThread = Thread.currentThread();
|
13 |
while (!canGrantWriteAccess(callingThread)){
|
18 |
writingThread = callingThread;
|
21 |
public synchronized void unlockWrite() throws InterruptedException{
|
23 |
if (writeAccesses == 0 ){
|
29 |
private boolean canGrantWriteAccess(Thread callingThread){
|
30 |
if (isOnlyReader(callingThread)) return true ;
|
31 |
if (hasReaders()) return false ;
|
32 |
if (writingThread == null ) return true ;
|
33 |
if (!isWriter(callingThread)) return false ;
|
37 |
private boolean hasReaders(){
|
38 |
return readingThreads.size() > 0 ;
|
41 |
private boolean isWriter(Thread callingThread){
|
42 |
return writingThread == callingThread;
|
45 |
private boolean isOnlyReader(Thread thread){
|
46 |
return readers == 1 && readingThreads.get(callingThread) != null ;
|
现在ReadWriteLock类就可以从读锁升级到写锁了。
写锁降级到读锁
有时拥有写锁的线程也希望得到读锁。如果一个线程拥有了写锁,那么自然其它线程是不可能拥有读锁或写锁了。所以对于一个拥有写锁的线程,再获得读锁,是不会有什么危险的。我们仅仅需要对上面canGrantReadAccess方法进行简单地修改:
1 |
public class ReadWriteLock{
|
2 |
private boolean canGrantReadAccess(Thread callingThread){
|
3 |
if (isWriter(callingThread)) return true ;
|
4 |
if (writingThread != null ) return false ;
|
5 |
if (isReader(callingThread) return true ;
|
6 |
if (writeRequests > 0 ) return false ;
|
可重入的ReadWriteLock的完整实现
下面是完整的ReadWriteLock实现。为了便于代码的阅读与理解,简单对上面的代码做了重构。重构后的代码如下。
001 |
public class ReadWriteLock{
|
002 |
private Map<Thread, Integer> readingThreads =
|
003 |
new HashMap<Thread, Integer>();
|
005 |
private int writeAccesses = 0 ;
|
006 |
private int writeRequests = 0 ;
|
007 |
private Thread writingThread = null ;
|
009 |
public synchronized void lockRead()
|
010 |
throws InterruptedException{
|
011 |
Thread callingThread = Thread.currentThread();
|
012 |
while (! canGrantReadAccess(callingThread)){
|
016 |
readingThreads.put(callingThread,
|
017 |
(getReadAccessCount(callingThread) + 1 ));
|
020 |
private boolean canGrantReadAccess(Thread callingThread){
|
021 |
if (isWriter(callingThread)) return true ;
|
022 |
if (hasWriter()) return false ;
|
023 |
if (isReader(callingThread)) return true ;
|
024 |
if (hasWriteRequests()) return false ;
|
029 |
public synchronized void unlockRead(){
|
030 |
Thread callingThread = Thread.currentThread();
|
031 |
if (!isReader(callingThread)){
|
032 |
throw new IllegalMonitorStateException(
|
033 |
"Calling Thread does not" +
|
034 |
" hold a read lock on this ReadWriteLock" );
|
036 |
int accessCount = getReadAccessCount(callingThread);
|
037 |
if (accessCount == 1 ){
|
038 |
readingThreads.remove(callingThread);
|
040 |
readingThreads.put(callingThread, (accessCount - 1 ));
|
045 |
public synchronized void lockWrite()
|
046 |
throws InterruptedException{
|
048 |
Thread callingThread = Thread.currentThread();
|
049 |
while (!canGrantWriteAccess(callingThread)){
|
054 |
writingThread = callingThread;
|
057 |
public synchronized void unlockWrite()
|
058 |
throws InterruptedException{
|
059 |
if (!isWriter(Thread.currentThread()){
|
060 |
throw new IllegalMonitorStateException(
|
061 |
"Calling Thread does not" +
|
062 |
" hold the write lock on this ReadWriteLock" );
|
065 |
if (writeAccesses == 0 ){
|
066 |
writingThread = null ;
|
071 |
private boolean canGrantWriteAccess(Thread callingThread){
|
072 |
if (isOnlyReader(callingThread)) return true ;
|
073 |
if (hasReaders()) return false ;
|
074 |
if (writingThread == null ) return true ;
|
075 |
if (!isWriter(callingThread)) return false ;
|
080 |
private int getReadAccessCount(Thread callingThread){
|
081 |
Integer accessCount = readingThreads.get(callingThread);
|
082 |
if (accessCount == null ) return 0 ;
|
083 |
return accessCount.intValue();
|
087 |
private boolean hasReaders(){
|
088 |
return readingThreads.size() > 0 ;
|
091 |
private boolean isReader(Thread callingThread){
|
092 |
return readingThreads.get(callingThread) != null ;
|
095 |
private boolean isOnlyReader(Thread callingThread){
|
096 |
return readingThreads.size() == 1 &&
|
097 |
readingThreads.get(callingThread) != null ;
|
100 |
private boolean hasWriter(){
|
101 |
return writingThread != null ;
|
104 |
private boolean isWriter(Thread callingThread){
|
105 |
return writingThread == callingThread;
|
108 |
private boolean hasWriteRequests(){
|
109 |
return this .writeRequests > 0 ;
|
在finally中调用unlock()
在利用ReadWriteLock来保护临界区时,如果临界区可能抛出异常,在finally块中调用readUnlock()和writeUnlock()就显得很重要了。这样做是为了保证ReadWriteLock能被成功解锁,然后其它线程可以请求到该锁。这里有个例子:
3 |
//do critical section code, which may throw exception
|
上面这样的代码结构能够保证临界区中抛出异常时ReadWriteLock也会被释放。如果unlockWrite方法不是在finally块中调用的,当临界区抛出了异常时,ReadWriteLock 会一直保持在写锁定状态,就会导致所有调用lockRead()或lockWrite()的线程一直阻塞。唯一能够重新解锁ReadWriteLock的因素可能就是ReadWriteLock是可重入的,当抛出异常时,这个线程后续还可以成功获取这把锁,然后执行临界区以及再次调用unlockWrite(),这就会再次释放ReadWriteLock。但是如果该线程后续不再获取这把锁了呢?所以,在finally中调用unlockWrite对写出健壮代码是很重要的。
(全文完)如果您喜欢此文请点赞,分享,评论。
相关推荐
在Java中,`java.util.concurrent.locks`包下的`ReadWriteLock`接口提供了读写锁的抽象定义,具体实现由`ReentrantReadWriteLock`类提供。`ReentrantReadWriteLock`实现了`ReadWriteLock`接口,提供了`readLock()`和...
下面我们将详细探讨Java读写锁的概念、实现原理以及如何在实际代码中应用。 1. **读写锁概念**: - 读写锁分为读锁(共享锁)和写锁(独占锁)。读锁允许多个线程同时读取数据,而写锁只允许一个线程进行写操作。 ...
Java readwritereentrantlock读写锁源码分析
在读写锁中,多个读取者可以同时访问资源,但写入者必须独占资源,以防止数据不一致。基于Zookeeper的分布式读写锁可以通过创建和删除临时节点来实现。 **三、Zookeeper实现读写锁** 1. **写锁**:当一个客户端请求...
Java 读写锁实现原理浅析是 Java 并发编程中一个非常重要的主题。在多线程编程中,读写锁是解决读写并发问题的常用机制。本文主要介绍了 Java 读写锁实现原理浅析,包括读写锁的定义、读写锁的实现原理、...
Java编程读写锁是Java并发编程中的一种重要机制,用于解决多线程访问同一个资源时的安全问题。在Java中,读写锁是通过ReadWriteLock接口实现的,该接口提供了readLock和writeLock两种锁的操作机制,一个资源可以被多...
本文将详细介绍Java中包括乐观锁、悲观锁、自旋锁、可重入锁、读写锁等多种锁机制的概念、特点、应用场景及其优化技术。 1. 乐观锁与悲观锁 乐观锁与悲观锁反映了对数据并发访问策略的不同预期。乐观锁假设数据通常...
在Java中,`java.util.concurrent.locks.ReentrantReadWriteLock`是标准的读写锁实现。这个类提供了可重入的特性,意味着一个线程在获得读锁或写锁后,可以再次请求相同的锁而不会被阻塞。这在处理递归调用时特别...
在Java并发编程中,读写锁是用于优化多线程访问共享资源的一种机制,它可以提高对数据的并发访问效率。本文将深入探讨Java中的两种读写锁:ReentrantReadWriteLock和StampedLock,并分析它们的工作原理、特点以及...
本文实例讲述了C#解决SQlite并发异常问题的方法。分享给大家供大家参考,...作者利用读写锁(ReaderWriterLock),达到了多线程安全访问的目标。 using System; using System.Collections.Generic; using System.Text;
本文将深入探讨标题和描述中提及的各种锁,包括乐观锁、悲观锁、分布式锁、可重入锁、互斥锁、读写锁、分段锁、类锁以及行级锁。 1. **乐观锁**:乐观锁假设多线程环境中的冲突较少,所以在读取数据时不加锁,只有...
例如,在读多写少的场景中,乐观锁和读写锁能提供更好的性能;而在写操作频繁的情况下,悲观锁可能是更好的选择。在Java中,`java.util.concurrent`包提供了丰富的工具,帮助开发者有效地管理并发。
Java多线程编程中,读写锁是一种优化并发访问共享资源的有效工具,它允许多个线程同时读取,但只允许一个线程写入。Java的`java.util.concurrent.locks.ReentrantReadWriteLock`类提供了可重入的读写锁功能。下面...
读写锁ReentrantReadWriteLock&StampLock详解_e读写锁ReentrantReadWriteLock&StampLock详解_e读写锁ReentrantReadWriteLock&StampLock详解_e读写锁ReentrantReadWriteLock&StampLock详解_e读写锁...
Java中提供了`java.util.concurrent.locks.ReadWriteLock`接口来支持这种模式,但在本案例中,我们将模拟实现一个读写锁来理解其基本原理。 1. **读写锁接口定义**: - `Lock`接口:这是基础的锁接口,提供了获取...
在Java多线程编程中,读写锁是一种高级的同步机制,它允许多个线程同时读取共享资源,但只允许一个线程写入。这种锁的引入提高了并发性能,特别是在读操作远多于写操作的场景下。Java 5开始,`java.util.concurrent....
Java的多线程编程中,读写锁(ReadWriteLock)是一种高效的并发控制机制,它将锁的权限进行了区分,允许多个线程同时读取资源,但仅允许一个线程进行写入操作。这种设计模式提高了数据共享的效率,因为读操作通常...
4. 锁分离:读写锁(ReentrantReadWriteLock)实现了一种分离锁机制,允许多个线程同时读取,但写入时独占资源,提高并发性能。 5. 偏向锁与轻量级锁:JVM对内置锁进行了优化,当锁竞争不激烈时,使用偏向锁或轻量...
本ppt介绍了排它锁等,源码深度理解读写锁,希望对大家有帮助!!!!!!!!!!!!!!!!!!!!!!!!!!!!
在Java编程语言中,读写文件是常见的操作,它涉及到对磁盘上文件内容的访问。这个"java简单的读写文件小程序"很可能是用来演示如何使用Java API进行文件操作的基本概念。下面,我们将深入探讨Java中读取和写入文件的...