相比饥饿与公平里Lock的实现,读写锁更复杂一些。假设你的程序中涉及到对一些共享资源的读和写操作,且写操作没有读操作那么频繁。在没有写操作的时候,两个线程同时读一个资源没有任何问题,所以应该允许多个线程能同时读取共享资源。但是如果有一个线程想去写这些共享资源,就不应该再有其它线程对该资源进行读或写(读-读能共存,读-写不能共存,写-写不能共存)。这就需要一个读/写锁来解决这个问题。

Java5在java.util.concurrent包中已经包含了读写锁。尽管如此,我们还是应该了解其实现背后的原理。

本文在Java中的读/写锁 这篇文章的基础上,加入了自己的理解和对代码的分析。

读/写锁的Java实现

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

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

如果某个线程想要读取资源,只要没有线程正在对该资源进行写操作且没有线程请求对该资源的写操作即可。如果读操作发生的比较频繁,又没有提升写操作的优先级,那么写操作的线程会一直阻塞,结果就会产生“饥饿”现象。因此,只有当没有线程锁住ReadWriteLock进行写操作,并且没有线程请求该锁准备执行写操作时,才能进行读操作(即:没有写操作占用锁,或者没有线程请求锁进行写操作,才能进行读操作)。

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

简单的实现出一个读/写锁,代码如下:

测试代码如下:

2个读线程,2个写线程测试结果如下:

首先介绍一下ReadWriteLock类里面的方法

  • lockRead() : 如果读线程或者请求读线程的个数大于0,则等待。读线程个数加1(加的1是已经被唤醒拿到锁的线程)。
  • lockWrite() : 请求线程个数加1,如果读线程或者写线程个数大于0,则等待。请求线程减1,写线程加1(此时写线程已经拿到锁,所以先减1再加1)。
  • unlockRead() : 读线程减1,唤醒所有等待ReadWriteLock实例锁的线程。
  • unlockWrite() : 写线程减1,唤醒所有等待ReadWriteLock实例锁的线程。

解释一下测试结果:

  • write线程1首先执行lockWrite(),此时writers和readers的值均为0,此时writers++,writers值变成了1。
  • read线程2执行lockRead(),此时writers值为1,调用wait(),释放锁,进行等待。
  • read线程1同上所述
  • write线程2执行lockWrite(),此时writers值为1,调用wait(),释放锁,进行等待。
  • write线程1工作完成,调用unlockWrite(),writers–,writers值变成0,调用notifyAll()唤醒以上等待的3个线程,跳出unlockWrite()后释放锁。
  • write线程2快于两个读线程得到CPU的响应,进入lockWrite(),拿到了锁,读线程则阻塞在lockRead()外。writers++,writers值变成1,跳出lockWrite()后释放锁。
  • read线程1 和read线程2 重新进入等待态。
  • write线程2工作完成,writers–,唤醒两个读线程。
  • read线程1 和read线程2 除去前后进入lockRead()的时间外,剩下的读操作几乎同时完成。

当然这只是运行情况的一种,假如上述情况中,write线程1工作完成后,不是write线程2先执行,而是另外两个读线程中的其中一个,则读线程会因为writeRequests的值为1,而调用wait()又进入等待状态,释放锁后,继续竞争,直到写线程获得对象锁。这也说明了为什么用notifyAll而不是用notify的原因,假如用notify唤醒,每次都是唤醒读线程,则写线程无法获取到锁。使用notifyAll另一个好处是程序中只剩下读线程时,可以全部唤醒,读线程并行执行。

由此可见,读/写锁适合读多,写少时使用。

读/写锁的重入

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

  • Thread 1 获得了读锁
  • Thread2 请求写锁,但因为Thread 1 持有了读锁,所以写锁请求被阻塞。
  • Thread 1 再想请求一次读锁,但因为Thread 2处于请求写锁的状态,所以想再次获取读锁也会被阻塞。

上面这种情形使用前面的ReadWriteLock就会被锁定,一种类似于死锁的情形。不会再有线程能够成功获取读锁或写锁了。

为了让ReadWriteLock可重入,需要对它做一些改进。下面会分别处理读锁的重入和写锁的重入。

读锁重入

为了让ReadWriteLock的读锁可重入,我们要先为读锁重入建立规则:

  • 要保证某个线程中的读锁可重入,要么满足获取读锁的条件(没有写或写请求),要么已经持有读锁(不管是否有写请求)。

要确定一个线程是否已经持有读锁,可以用一个map来存储已经持有读锁的线程以及对应线程获取读锁的次数,当需要判断某个线程能否获得读锁时,就利用map中存储的数据进行判断。

改造一下lockRead和unlockRead的代码

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

写锁的重入

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

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

读锁升级到写锁

有时,我们希望一个拥有读锁的线程,也能获得写锁。想要允许这样的操作,要求这个线程是唯一一个拥有读锁的线程。所以我们需要对写锁部分搞点事情。

写锁降级到读锁

有时拥有写锁的线程也希望得到读锁。如果一个线程拥有了写锁,那么自然其它线程是不可能拥有读锁或写锁了。所以对于一个拥有写锁的线程,再获得读锁,是不会有什么危险的。把读锁中的canGrantReadAccess方法进行修改

ReadWriteLock完整代码

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

在finally中调用unlock()

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

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