简单分析线程获取ReentrantReadWriteLock 读锁的规则

 1. 问题

最近有同事问了我一个问题,在Java编程中,当有一条线程要获取ReentrantReadWriteLock的读锁,此时已经有其他线程获得了读锁,AQS队列里也有线程在等待写锁。由于读锁是共享锁,当前线程是马上获得读锁,还是排队?如果是马上获得读锁,那岂不是阻塞的等待写锁的线程有可能一直(或长时间)拿不到写锁(写锁饥饿)?

带着这个问题,我打开读写锁的源码,来看一下JDK是怎么实现的。(注:读写锁指ReentrantReadWriteLock, 以下说到的读锁和写锁,都是指属于同一个读写锁的情况。读锁和共享锁,写锁和独占锁,在这里是同样的意思。如无特殊说明,提到的模式都是默认的非公平模式)

2. JUC万物皆有AQS

2.1 读锁的实现。

先来看看读锁的实现。持有一个AQS,所以说,JUC万物皆有AQS(大雾)。

顺便提一下写锁,写锁也是类似的实现,而且传入的是同一个读写锁,那么读锁和写锁,都拥有同一个AQS,这样才能实现互相阻塞。

读锁是共享模式。

2.2 tryAcquireShared(int arg)的实现。

熟悉AQS的同学就知道,共享锁的实现,AQS已经写好了流程。但留下了一个钩子,tryAcquireShared(int arg) 供各种场景实现。

那么我们就来看看,读写锁里面,共享锁(读锁)是怎么实现的。

step1. 红框一,如果当前已经有线程持有了独占锁(即写锁),且不是当前线程持有,那么无法重入,直接返回-1,获取共享锁失败。

step2. 如果step1的情况被排除,那么进行readerShouldBlock()的判断。在读写锁中,AQS有两种实现,公平和非公平模式,默认是非公平模式。

也就是说,上面所说的sync变量的实际类型,可以是公平模式,也可以是非公平模式。

因此,readerShouldBlock()也有公平和非公平两种不同的实现。

公平模式下,只要前面有阻塞排队的节点,就返回true,表示不能抢占。

非公平模式下,看看第一个等待的阻塞节点是不是独占式的,如果是,返回true,有可能不可以抢在人家前面(为什么是有可能?要考虑可重入的场景,下面分析)。这是为了避免写锁饥饿。

所以,如果readerShouldBlock()返回false,并且读锁获取的总次数不溢出,且CAS成功,说明获取共享锁成功,下面进入if块,设置一些变量,并将当前线程持有的该读锁的次数递增加1,返回成功标志。

看到这里,也许你会有疑惑,仅仅是因为CAS失败,就获取共享锁失败了吗?而且,ReentrantReadWriteLock是一个可重入锁,这里也没看到有重入的地方啊。

别急,如果step2失败,会进入step3,到第三个红框,进入fullTryAcquireShared(Thread current)方法。

2.3  final int fullTryAcquireShared(Thread current)

这个方法比较长,里面用了for(;;) 自旋CAS,为什么呢?因为CAS还是可能会失败啊……失败就得继续再尝试一把。

我就贴出for(;;) 里的代码,分为两段,第一段判断是否可以尝试获取锁(与上面类似,加了重入的判断),第二段CAS和成功后的一些操作。

先看第一段,判断是否可以尝试获取锁。

step1. 如果有线程持有独占锁,并且不是当前线程,返回失败标志-1。如果是当前线程,由于可重入的语义,通过了判断,直接跑到第二段代码了。说明在持有独占锁的情况下可以获取共享锁(锁降级)。

step2. 如果当前没有线程持有独占锁,那么再来看看熟悉的readerShouldBlock()。通过上面的分析我们知道,在公平模式下有节点在阻塞就得排队,在非公平模式下有可能不可以抢在人家前面。为什么是有可能?因为要考虑可重入的场景。

如果firstReader是当前线程,或者当前线程的cachedHoldCounter变量的count不为0(表示当前线程已经持有了该共享锁),均说明当前线程已经持有共享锁,此次获取共享锁是重入,这也是允许的,可以通过判断。

如果可以顺利通过上面两步判断,说明获取共享锁成功,下面开始熟悉的CAS。 

 

失败了咋办?别忘记是自旋啊,外层是for(;;),那就再来一发~~。当然还得再来一遍第一段的判断。

3. 结论

经过上面的分析,可以来回答我的同事的问题了。

在Java编程中,当有一条线程要获取ReentrantReadWriteLock的读锁,此时已经有其他线程获得了读锁,AQS队列里也有线程在等待写锁。由于读锁是共享锁,当前线程是马上获得读锁,还是排队?如果是马上获得读锁,那岂不是阻塞的等待写锁的线程有可能一直(或长时间)拿不到写锁(写锁饥饿)?

1.如果已经有线程持有独占锁

1.1 该线程不是当前线程,不用想了,乖乖排队;

1.2 该线程就是当前线程,重入,CAS获取共享锁;

2.如果没有线程持有独占锁,检查当前线程是否需要block(readerShouldBlock方法)。

block的判断,有两种模式,公平和非公平(默认模式)。如果不需要block, 必须满足:公平模式下,没有节点在AQS等待;非公平模式下,AQS第一个等待的节点不是独占式的;

2.1 不需要block,可以CAS获取共享锁;

2.2 需要block;

2.2.1 当前线程已经持有了共享锁,重入,还是可以CAS获取共享锁;

2.2.2 当前线程前没有已经持有共享锁,则获取失败,只能排队。

 

上面是根据代码逻辑整理的,可以换为更简洁的语言。

如果当前线程已经持有独占锁或共享锁(重入)或不需要block,则CAS获取共享锁;否则,排队。

readerShouldBlock()判断第一个节点是获取共享锁或独占锁,在不考虑重入的情况下,是什么意思呢?

1. 第一个节点是等待独占锁的场景,说明下一个就是它了,不能抢它的,抢不到;

2. 第一个节点是等待共享锁的场景,说明第一个节点,

2.1 在等待持有独占锁的线程释放独占锁,这种必然是抢不到的。

2.2 持有共享锁的线程还在唤醒后续节点的过程中,允许你去抢一下。当然,不意味着一定可以抢成功。

如果是2.2持有共享锁的线程在唤醒后续节点过程中,理论上是可能获取得到的。这种情况概率较小,我没重现过。

回到这个问题。当前线程并没有获取到写锁或读锁,不能重入;AQS中,第一个等待的大概率是想要获取独占锁的节点,必须block,所以当前线程只能排队,并不会出现阻塞的想获取写锁的节点一直拿不到写锁的情况;如果刚好没有完全唤醒,那么可能是可以抢占的。但也不会一直阻塞,因为唤醒节点获取读锁的过程是很快的。

总之,获取读锁的机制,记住这个结论就行。

如果当前线程已经持有独占锁或共享锁(重入)或不需要block,则CAS获取共享锁;否则,排队。

4. 举个栗子

第一个节点是独占锁的场景,不能抢占

 1 package com.khlin.my.test;
 2 
 3 import java.util.concurrent.locks.ReentrantReadWriteLock;
 4 
 5 public class RRWLockTest {
 6 
 7     public static void main(String[] args) throws InterruptedException {
 8         final ReentrantReadWriteLock LOCK = new ReentrantReadWriteLock();
 9 
10         Thread reader1 = new Thread(new Runnable() {
11             public void run() {
12                 try {
13                     LOCK.readLock().lock();
14                     System.out.println("reader1 locked.");
15                     Thread.sleep(3000L);
16                     System.out.println("reader1 finished.");
17                 } catch (InterruptedException e) {
18                     e.printStackTrace();
19                 } finally {
20                     LOCK.readLock().unlock();
21                 }
22             }
23         });
24 
25         Thread reader2 = new Thread(new Runnable() {
26             public void run() {
27                 try {
28                     LOCK.readLock().lock();
29                     System.out.println("reader2 locked.");
30                     System.out.println("reader2 finished.");
31                 } finally {
32                     LOCK.readLock().unlock();
33                 }
34             }
35         });
36 
37         Thread writer = new Thread(new Runnable() {
38             public void run() {
39                 try{
40                     LOCK.writeLock().lock();
41                     System.out.println("writer locked.");
42                     System.out.println("writer finished.");
43                 }finally {
44                     LOCK.writeLock().unlock();
45                 }
46             }
47         });
48         reader1.start();
49         Thread.sleep(1000L);
50         writer.start();
51         Thread.sleep(1000L);
52         reader2.start();
53     }
54 }

reader1获取了读锁,正在执行,随后writer来获取写锁,失败,入队等待。reader2由于writer正在等待(通过readerShouldBlock判断),无法获取读锁,入队,等待。输出如下:

 

posted @ 2019-07-24 00:38  kingsleylam  阅读(535)  评论(0编辑  收藏