文档章节

Java中的读/写锁

LCZ777
 LCZ777
发布于 2014/05/26 16:10
字数 2993
阅读 8
收藏 0

读/写锁的Java实现

先让我们对读写访问资源的条件做个概述:

读取 没有线程正在做写操作,且没有线程在请求写操作。

写入 没有线程正在做读写操作。

如果某个线程想要读取资源,只要没有线程正在对该资源进行写操作且没有线程请求对该资源的写操作即可。我们假设对写操作的请求比对读操作的请求更重要,就要提升写请求的优先级。此外,如果读操作发生的比较频繁,我们又没有提升写操作的优先级,那么就会产生“饥饿”现象。请求写操作的线程会一直阻塞,直到所有的读线程都从ReadWriteLock上解锁了。如果一直保证新线程的读操作权限,那么等待写操作的线程就会一直阻塞下去,结果就是发生“饥饿”。因此,只有当没有线程正在锁住ReadWriteLock进行写操作,且没有线程请求该锁准备执行写操作时,才能保证读操作继续。

当其它线程没有对共享资源进行读操作或者写操作时,某个线程就有可能获得该共享资源的写锁,进而对共享资源进行写操作。有多少线程请求了写锁以及以何种顺序请求写锁并不重要,除非你想保证写锁请求的公平性。

按照上面的叙述,简单的实现出一个读/写锁,代码如下

01 public class ReadWriteLock{
02     private int readers = 0;
03     private int writers = 0;
04     private int writeRequests = 0;
05  
06     public synchronized void lockRead()
07         throws InterruptedException{
08         while(writers > 0 || writeRequests > 0){
09             wait();
10         }
11         readers++;
12     }
13  
14     public synchronized void unlockRead(){
15         readers--;
16         notifyAll();
17     }
18  
19     public synchronized void lockWrite()
20         throws InterruptedException{
21         writeRequests++;
22  
23         while(readers > 0 || writers > 0){
24             wait();
25         }
26         writeRequests--;
27         writers++;
28     }
29  
30     public synchronized void unlockWrite()
31         throws InterruptedException{
32         writers--;
33         notifyAll();
34     }
35 }

ReadWriteLock类中,读锁和写锁各有一个获取锁和释放锁的方法。

读锁的实现在lockRead()中,只要没有线程拥有写锁(writers==0),且没有线程在请求写锁(writeRequests ==0),所有想获得读锁的线程都能成功获取。

写锁的实现在lockWrite()中,当一个线程想获得写锁的时候,首先会把写锁请求数加1(writeRequests++),然后再去判断是否能够真能获得写锁,当没有线程持有读锁(readers==0 ),且没有线程持有写锁(writers==0)时就能获得写锁。有多少线程在请求写锁并无关系。

需要注意的是,在两个释放锁的方法(unlockRead,unlockWrite)中,都调用了notifyAll方法,而不是notify。要解释这个原因,我们可以想象下面一种情形:

如果有线程在等待获取读锁,同时又有线程在等待获取写锁。如果这时其中一个等待读锁的线程被notify方法唤醒,但因为此时仍有请求写锁的线程存在(writeRequests>0),所以被唤醒的线程会再次进入阻塞状态。然而,等待写锁的线程一个也没被唤醒,就像什么也没发生过一样(译者注:信号丢失现象)。如果用的是notifyAll方法,所有的线程都会被唤醒,然后判断能否获得其请求的锁。

用notifyAll还有一个好处。如果有多个读线程在等待读锁且没有线程在等待写锁时,调用unlockWrite()后,所有等待读锁的线程都能立马成功获取读锁 —— 而不是一次只允许一个。

读/写锁的重入

上面实现的读/写锁(ReadWriteLock) 是不可重入的,当一个已经持有写锁的线程再次请求写锁时,就会被阻塞。原因是已经有一个写线程了——就是它自己。此外,考虑下面的例子:

  1. Thread 1 获得了读锁
  2. Thread 2 请求写锁,但因为Thread 1 持有了读锁,所以写锁请求被阻塞。
  3. 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>();
04  
05     private int writers = 0;
06     private int writeRequests = 0;
07  
08     public synchronized void lockRead()
09         throws InterruptedException{
10         Thread callingThread = Thread.currentThread();
11         while(! canGrantReadAccess(callingThread)){
12             wait();                                                                  
13         }
14  
15         readingThreads.put(callingThread,
16             (getAccessCount(callingThread) + 1));
17     }
18  
19     public synchronized void unlockRead(){
20         Thread callingThread = Thread.currentThread();
21         int accessCount = getAccessCount(callingThread);
22         if(accessCount == 1) {
23             readingThreads.remove(callingThread);
24         } else {
25             readingThreads.put(callingThread, (accessCount -1));
26         }
27         notifyAll();
28     }
29  
30     private boolean canGrantReadAccess(Thread callingThread){
31         if(writers > 0) return false;
32         if(isReader(callingThread) return true;
33         if(writeRequests > 0) return false;
34         return true;
35     }
36  
37     private int getReadAccessCount(Thread callingThread){
38         Integer accessCount = readingThreads.get(callingThread);
39         if(accessCount == null) return 0;
40         return accessCount.intValue();
41     }
42  
43     private boolean isReader(Thread callingThread){
44         return readingThreads.get(callingThread) != null;
45     }
46 }

代码中我们可以看到,只有在没有线程拥有写锁的情况下才允许读锁的重入。此外,重入的读锁比写锁优先级高。

写锁重入

仅当一个线程已经持有写锁,才允许写锁重入(再次获得写锁)。下面是方法lockWrite和unlockWrite修改后的的代码。

01 public class ReadWriteLock{
02     private Map<Thread, Integer> readingThreads =
03         new HashMap<Thread, Integer>();
04  
05     private int writeAccesses    = 0;
06     private int writeRequests    = 0;
07     private Thread writingThread = null;
08  
09     public synchronized void lockWrite()
10         throws InterruptedException{
11         writeRequests++;
12         Thread callingThread = Thread.currentThread();
13         while(!canGrantWriteAccess(callingThread)){
14             wait();
15         }
16         writeRequests--;
17         writeAccesses++;
18         writingThread = callingThread;
19     }
20  
21     public synchronized void unlockWrite()
22         throws InterruptedException{
23         writeAccesses--;
24         if(writeAccesses == 0){
25             writingThread = null;
26         }
27         notifyAll();
28     }
29  
30     private boolean canGrantWriteAccess(Thread callingThread){
31         if(hasReaders()) return false;
32         if(writingThread == null)    return true;
33         if(!isWriter(callingThread)) return false;
34         return true;
35     }
36  
37     private boolean hasReaders(){
38         return readingThreads.size() > 0;
39     }
40  
41     private boolean isWriter(Thread callingThread){
42         return writingThread == callingThread;
43     }
44 }

注意在确定当前线程是否能够获取写锁的时候,是如何处理的。

读锁升级到写锁

有时,我们希望一个拥有读锁的线程,也能获得写锁。想要允许这样的操作,要求这个线程是唯一一个拥有读锁的线程。writeLock()需要做点改动来达到这个目的:

01 public class ReadWriteLock{
02     private Map<Thread, Integer> readingThreads =
03         new HashMap<Thread, Integer>();
04  
05     private int writeAccesses    = 0;
06     private int writeRequests    = 0;
07     private Thread writingThread = null;
08  
09     public synchronized void lockWrite()
10         throws InterruptedException{
11         writeRequests++;
12         Thread callingThread = Thread.currentThread();
13         while(!canGrantWriteAccess(callingThread)){
14             wait();
15         }
16         writeRequests--;
17         writeAccesses++;
18         writingThread = callingThread;
19     }
20  
21     public synchronized void unlockWrite() throws InterruptedException{
22         writeAccesses--;
23         if(writeAccesses == 0){
24             writingThread = null;
25         }
26         notifyAll();
27     }
28  
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;
34         return true;
35     }
36  
37     private boolean hasReaders(){
38         return readingThreads.size() > 0;
39     }
40  
41     private boolean isWriter(Thread callingThread){
42         return writingThread == callingThread;
43     }
44  
45     private boolean isOnlyReader(Thread thread){
46         return readers == 1 && readingThreads.get(callingThread) != null;
47     }
48 }

现在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;
7         return true;
8     }
9 }

可重入的ReadWriteLock的完整实现

下面是完整的ReadWriteLock实现。为了便于代码的阅读与理解,简单对上面的代码做了重构。重构后的代码如下。

001 public class ReadWriteLock{
002     private Map<Thread, Integer> readingThreads =
003         new HashMap<Thread, Integer>();
004  
005     private int writeAccesses    = 0;
006     private int writeRequests    = 0;
007     private Thread writingThread = null;
008  
009     public synchronized void lockRead()
010         throws InterruptedException{
011         Thread callingThread = Thread.currentThread();
012         while(! canGrantReadAccess(callingThread)){
013             wait();
014         }
015  
016         readingThreads.put(callingThread,
017             (getReadAccessCount(callingThread) + 1));
018     }
019  
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;
025         return true;
026     }
027  
028  
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");
035         }
036         int accessCount = getReadAccessCount(callingThread);
037         if(accessCount == 1){
038             readingThreads.remove(callingThread);
039         } else {
040             readingThreads.put(callingThread, (accessCount -1));
041         }
042         notifyAll();
043     }
044  
045     public synchronized void lockWrite()
046         throws InterruptedException{
047         writeRequests++;
048         Thread callingThread = Thread.currentThread();
049         while(!canGrantWriteAccess(callingThread)){
050             wait();
051         }
052         writeRequests--;
053         writeAccesses++;
054         writingThread = callingThread;
055     }
056  
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");
063         }
064         writeAccesses--;
065         if(writeAccesses == 0){
066             writingThread = null;
067         }
068         notifyAll();
069     }
070  
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;
076         return true;
077     }
078  
079  
080     private int getReadAccessCount(Thread callingThread){
081         Integer accessCount = readingThreads.get(callingThread);
082         if(accessCount == null) return 0;
083         return accessCount.intValue();
084     }
085  
086  
087     private boolean hasReaders(){
088         return readingThreads.size() > 0;
089     }
090  
091     private boolean isReader(Thread callingThread){
092         return readingThreads.get(callingThread) != null;
093     }
094  
095     private boolean isOnlyReader(Thread callingThread){
096         return readingThreads.size() == 1 &&
097             readingThreads.get(callingThread) != null;
098     }
099  
100     private boolean hasWriter(){
101         return writingThread != null;
102     }
103  
104     private boolean isWriter(Thread callingThread){
105         return writingThread == callingThread;
106     }
107  
108     private boolean hasWriteRequests(){
109         return this.writeRequests > 0;
110     }
111 }

在finally中调用unlock()

在利用ReadWriteLock来保护临界区时,如果临界区可能抛出异常,在finally块中调用readUnlock()和writeUnlock()就显得很重要了。这样做是为了保证ReadWriteLock能被成功解锁,然后其它线程可以请求到该锁。这里有个例子:

1 lock.lockWrite();
2 try{
3     //do critical section code, which may throw exception
4 } finally {
5     lock.unlockWrite();
6 }

上面这样的代码结构能够保证临界区中抛出异常时ReadWriteLock也会被释放。如果unlockWrite方法不是在finally块中调用的,当临界区抛出了异常时,ReadWriteLock 会一直保持在写锁定状态,就会导致所有调用lockRead()或lockWrite()的线程一直阻塞。唯一能够重新解锁ReadWriteLock的因素可能就是ReadWriteLock是可重入的,当抛出异常时,这个线程后续还可以成功获取这把锁,然后执行临界区以及再次调用unlockWrite(),这就会再次释放ReadWriteLock。但是如果该线程后续不再获取这把锁了呢?所以,在finally中调用unlockWrite对写出健壮代码是很重要的。

本文转载自:

上一篇: 重入锁死
下一篇: Java中的锁
LCZ777
粉丝 53
博文 248
码字总数 65899
作品 0
杭州
程序员
私信 提问
JUC锁框架——ReadWriteLock

ReadWriteLock简单介绍 ReadWriteLock管理一组锁,一个是只读的锁,一个是写锁。读锁可以在没有写锁的时候被多个线程同时持有,写锁是独占的。相对于互斥锁而言,ReadWriteLoc允许更高的并发...

长头发-dawn
2018/09/17
32
0
死磕 java同步系列之ReentrantReadWriteLock源码解析

问题 (1)读写锁是什么? (2)读写锁具有哪些特性? (3)ReentrantReadWriteLock是怎么实现读写锁的? (4)如何使用ReentrantReadWriteLock实现高效安全的TreeMap? 简介 读写锁是一种特...

彤哥读源码
06/13
99
6
Java 8新特性探究(十)StampedLock将是解决同步问题的新宠

Java8就像一个宝藏,一个小的API改进,也足与写一篇文章,比如同步,一直是多线程并发编程的一个老话题,相信没有人喜欢同步的代码,这会降低应用的吞吐量等性能指标,最坏的时候会挂起死机,...

OSC闲人
2014/05/13
7.4K
30
并发编程之——读锁源码分析(解释关于锁降级的争议)

1. 前言 在前面的文章 并发编程之——写锁源码分析中,我们分析了 1.8 JUC 中读写锁中的写锁的获取和释放过程,今天来分析一下读锁的获取和释放过程,读锁相比较写锁要稍微复杂一点,其中还有...

stateIs0
2018/01/12
0
0
深入理解 java volatile

在开始讲之前,我们需要对以下的内容有所了解. java 内存模型(JMM) 在java中,java堆内存是存在数据共享的,这些共享数据的通信就是通过java内存模型(JMM)来控制的. JMM决定一个线程对共享数据的...

jimmie_yang
2018/10/13
0
0

没有更多内容

加载失败,请刷新页面

加载更多

医疗在线客服咨询系统有哪些特点?

随着中国互联网网站的的快速发展,至今医疗行业已经拥有了独立的的运营网站,其中最具特色的便属于医疗在线客服咨询系统,医疗在线客服咨询系统为每个访问网站的患者提供即时的网络在线客服服...

唯喏
今天
10
0
skywalking(容器部署)

skywalking(容器部署) 标签(空格分隔): APM [toc] 1. Elasticsearch SkywalkingElasticsearch 5.X(部分功能报错、拓扑图不显示) Skywalking需要Elasticsearch 6.X docker network create......

JUKE
今天
8
0
解决Unable to find a single main class from the following candidates [xxx,xxx]

一、问题描述 1.1 开发环境配置 pom.xml <plugin><groupId>org.springframework.boot</groupId><artifactId>spring-boot-maven-plugin</artifactId><!--一定要对上springboot版本号,因......

TeddyIH
今天
7
0
玩转Spring Boot 注册Servlet、Filter、Listener

玩转Spring Boot 注册Servlet、Filter、Listener JAVA架构师Ya七月 2019-08-23 玩转Spring Boot 注册Servlet、Filter、Listener 在Servlet 3.0之前我们都是使用web.xml进行配置,需要增加Ser...

Java架构师ya七
今天
5
0
Dubbo服务限制大数据传输抛Data length too large: 13055248, max payload: 8388608解决方案

当dubbo服务提供者向消费层传输大数据容量数据时,会受到Dubbo的限制,报类似如下异常: 2019-08-23 11:04:31.711 [ DubboServerHandler-XX.XX.XX.XXX:20880-thread-87] - [ ERROR ] [com.al...

huangkejie
今天
9
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部