聊聊高并发（二十八）解析java.util.concurrent各个组件（十）理解ReentrantReadWriteLock可重入读-写锁

这篇讲讲ReentrantReadWriteLock可重入读写锁，它不仅是读写锁的实现，并且支持可重入性。聊聊高并发（十五）实现一个简单的读-写锁(共享-排他锁) 这篇讲了如何模拟一个读写锁。

可重入的读写锁的特点是

1. 当有线程获取读锁时，不允许再有线程获得写锁

2. 当有线程获得写锁时，不允许其他线程获得读锁和写锁

这里隐含着几层含义：

static final int SHARED_SHIFT = 16;
static final int SHARED_UNIT = (1 << SHARED_SHIFT);
static final int MAX_COUNT = (1 << SHARED_SHIFT) - 1;
static final int EXCLUSIVE_MASK = (1 << SHARED_SHIFT) - 1;
/** Returns the number of shared holds represented in count */
static int sharedCount(int c) { return c >>> SHARED_SHIFT; }
/** Returns the number of exclusive holds represented in count */
static int exclusiveCount(int c) { return c & EXCLUSIVE_MASK; }

1. 可以同时有多个线程同时获得读锁，进入临界区。这时候的读锁的行为和Semaphore信号量是类似的

2. 由于是可重入的，所以1个线程如果获得了读锁，那么它可以重入这个读锁

3. 如果1个线程获得了读锁，那么它不能同时再获得写锁，这个就是所谓的“锁升级”，读锁升级到写锁可能会造成死锁，所以是不允许的

4. 如果1个线程获得了写锁，那么不允许其他线程再获得读锁和写锁，但是它自己可以获得读锁，就是所谓的“锁降级”，锁降级是允许的

关于读写锁的实现还要考虑的几个要点：

1. 释放锁时的优先级问题，是让写锁先获得还是先让读锁先获得

2. 是否允许读线程插队

3. 是否允许写线程插队，因为读写锁一般用在大量读，少量写的情况，如果写线程没有优先级，那么可能造成写线程的饥饿

4. 锁的升降级问题，一般是允许1个线程的写锁降级为读锁，不允许读锁升级成写锁

带着问题看看ReentrantReadWriteLock的源码。它同样提供了Sync来继承AQS并提供扩展，但是它的Sync相比较Semaphore和CountDownLatch要更加复杂。

1. 把State状态作为一个读写锁的计数器，包括了重入的次数。state是32位的int值，所以把高位16位作为读锁的计数器，低位的16位作为写锁的计数器，并提供了响应的读写这两个计数器的位操作方法。

计算sharedCount时，采用无符号的移位操作，右移16位就是读锁计数器的值

写锁直接用EXCLUSIVE_MASK和state做与运算，EXCLUSIVE_MASK的值是00000000000000001111111111111111，相当于计算了低位16位的值

需要注意计算出来的值包含了重入的次数。所以MAX_COUNT限定了最大值是2^17 - 1

static final int SHARED_SHIFT = 16;
static final int SHARED_UNIT = (1 << SHARED_SHIFT);
static final int MAX_COUNT = (1 << SHARED_SHIFT) - 1;
static final int EXCLUSIVE_MASK = (1 << SHARED_SHIFT) - 1;
/** Returns the number of shared holds represented in count */
static int sharedCount(int c) { return c >>> SHARED_SHIFT; }
/** Returns the number of exclusive holds represented in count */
static int exclusiveCount(int c) { return c & EXCLUSIVE_MASK; }

HoldCount类用来计算1个线程的重入次数，并使用了1个ThreadLocal类型的HoldCounter，可以记录每个线程的锁的重入次数。 cachedHoldCounter记录了最后1个获取读锁的线程的重入次数。 firstReader指向了第一个获取读锁的线程，firstReaderHoldCounter记录了第一个获取读锁的线程的重入次数

static final class HoldCounter {
int count = 0;
// Use id, not reference, to avoid garbage retention
final long tid = Thread.currentThread().getId();
}
/**
* ThreadLocal subclass. Easiest to explicitly define for sake
* of deserialization mechanics.
*/
static final class ThreadLocalHoldCounter
extends ThreadLocal<HoldCounter> {
public HoldCounter initialValue() {
return new HoldCounter();
}
}
/**
* The hold count of the last thread to successfully acquire
* readLock. This saves ThreadLocal lookup in the common case
* where the next thread to release is the last one to
* acquire. This is non-volatile since it is just used
* as a heuristic, and would be great for threads to cache.
*
* <p>Can outlive the Thread for which it is caching the read
* hold count, but avoids garbage retention by not retaining a
* reference to the Thread.
*
* <p>Accessed via a benign data race; relies on the memory
* model's final field and out-of-thin-air guarantees.
*/
private transient HoldCounter cachedHoldCounter;

Sync提供了两个抽象方法给子类扩展，用来表示读锁和写锁是否应该阻塞等待

/**
* Returns true if the current thread, when trying to acquire
* the read lock, and otherwise eligible to do so, should block
* because of policy for overtaking other waiting threads.
*/
abstract boolean readerShouldBlock();
/**
* Returns true if the current thread, when trying to acquire
* the write lock, and otherwise eligible to do so, should block
* because of policy for overtaking other waiting threads.
*/
abstract boolean writerShouldBlock();

写锁的tryXXX获取和释放

1. 写锁释放时，由于没有其他线程获得临界区，它的tryRelease()方法只需要设置状态的值，通过exclusiveCount计算写锁的计数器，如果为0表示释放了写锁，就把exclusiveOwnerThread设置为null.

2. 写锁的tryAcquire获取时，

先判断状态是否为0，为0表示没有线程获得锁，就可以直接设置状态，然后把exclusiveOwnerThread设置为当前线程

如果状态不为0，那表示有几种可能：写锁为0，读锁不为0；写锁不为0，读锁为0，写锁不为0，读锁也不为0。

所以它先判断写锁是否为0，写锁为0，那么表示读锁肯定不会为0，就失败，

或者写锁不为0，但是exclusiveOwnerThread不是自己，那么表示已经有其他线程获得了写锁，就失败

写锁不为0，并且exclusiveOwnerThread是自己，那么肯定表示是写锁的重入的情况，所以设置state状态，返回成功。

protected final boolean tryRelease(int releases) {
if (!isHeldExclusively())
throw new IllegalMonitorStateException();
int nextc = getState() - releases;
boolean free = exclusiveCount(nextc) == 0;
if (free)
setExclusiveOwnerThread(null);
setState(nextc);
return free;
}
protected final boolean tryAcquire(int acquires) {
/*
* Walkthrough:
* 1. If read count nonzero or write count nonzero
* and owner is a different thread, fail.
* 2. If count would saturate, fail. (This can only
* happen if count is already nonzero.)
* 3. Otherwise, this thread is eligible for lock if
* it is either a reentrant acquire or
* queue policy allows it. If so, update state
* and set owner.
*/
Thread current = Thread.currentThread();
int c = getState();
int w = exclusiveCount(c);
if (c != 0) {
// (Note: if c != 0 and w == 0 then shared count != 0)
if (w == 0 || current != getExclusiveOwnerThread())
return false;
if (w + exclusiveCount(acquires) > MAX_COUNT)
throw new Error("Maximum lock count exceeded");
// Reentrant acquire
setState(c + acquires);
return true;
}
if (writerShouldBlock() ||
!compareAndSetState(c, c + acquires))
return false;
setExclusiveOwnerThread(current);
return true;
}

读锁的tryXXX获取和释放

1. 读锁释放时基于共享的方式，修改线程各自的HoldCounter的值，最后采用位操作修改位于state的总体的读锁计数器。tryReleaseShared()之后具体的释放后续线程的操作由AQS根据队列状态来决定。

2. 读所获取时先看写锁的计数器，如果写锁已经被获取，并且不是当前线程所获取的，就直接失败返回

这里会进行一次快速路径获取，尝试获取一次，如果readShouldBlock()返回false，并且CAS操作成功了，意思是可以获得锁，就更新相关读锁计数器

否则就进行轮询方式的获取fullTryAcquireShared()

也就是说如果当前没有线程获取写锁，或者是自己获取写锁，就可以获取读锁

一个线程获取了写锁之后，它还可以获取读锁，也就是所谓的“锁降级”，但这时候其他线程无法获取读锁，在检查到有其他写锁存在时就退出了

protected final boolean tryReleaseShared(int unused) {
Thread current = Thread.currentThread();
if (firstReader == current) {
// assert firstReaderHoldCount > 0;
if (firstReaderHoldCount == 1)
firstReader = null;
else
firstReaderHoldCount--;
} else {
HoldCounter rh = cachedHoldCounter;
if (rh == null || rh.tid != current.getId())
rh = readHolds.get();
int count = rh.count;
if (count <= 1) {
readHolds.remove();
if (count <= 0)
throw unmatchedUnlockException();
}
--rh.count;
}
for (;;) {
int c = getState();
int nextc = c - SHARED_UNIT;
if (compareAndSetState(c, nextc))
// Releasing the read lock has no effect on readers,
// but it may allow waiting writers to proceed if
// both read and write locks are now free.
return nextc == 0;
}
}
protected final int tryAcquireShared(int unused) {
/*
* Walkthrough:
* 1. If write lock held by another thread, fail.
* 2. Otherwise, this thread is eligible for
* lock wrt state, so ask if it should block
* because of queue policy. If not, try
* to grant by CASing state and updating count.
* Note that step does not check for reentrant
* acquires, which is postponed to full version
* to avoid having to check hold count in
* the more typical non-reentrant case.
* 3. If step 2 fails either because thread
* apparently not eligible or CAS fails or count
* saturated, chain to version with full retry loop.
*/
Thread current = Thread.currentThread();
int c = getState();
if (exclusiveCount(c) != 0 &&
getExclusiveOwnerThread() != current)
return -1;
int r = sharedCount(c);
if (!readerShouldBlock() &&
r < MAX_COUNT &&
compareAndSetState(c, c + SHARED_UNIT)) {
if (r == 0) {
firstReader = current;
firstReaderHoldCount = 1;
} else if (firstReader == current) {
firstReaderHoldCount++;
} else {
HoldCounter rh = cachedHoldCounter;
if (rh == null || rh.tid != current.getId())
cachedHoldCounter = rh = readHolds.get();
else if (rh.count == 0)
readHolds.set(rh);
rh.count++;
}
return 1;
}
return fullTryAcquireShared(current);
}
/**
* Full version of acquire for reads, that handles CAS misses
* and reentrant reads not dealt with in tryAcquireShared.
*/
final int fullTryAcquireShared(Thread current) {
/*
* This code is in part redundant with that in
* tryAcquireShared but is simpler overall by not
* complicating tryAcquireShared with interactions between
* retries and lazily reading hold counts.
*/
HoldCounter rh = cachedHoldCounter;
if (rh == null || rh.tid != current.getId())
rh = readHolds.get();
for (;;) {
int c = getState();
int w = exclusiveCount(c);
if ((w != 0 && getExclusiveOwnerThread() != current) ||
((rh.count | w) == 0 && readerShouldBlock(current)))
return -1;
if (sharedCount(c) == MAX_COUNT)
throw new Error("Maximum lock count exceeded");
if (compareAndSetState(c, c + SHARED_UNIT)) {
cachedHoldCounter = rh; // cache for release
rh.count++;
return 1;
}
}
}

tryWriteLock和tryReadLock操作和上面的操作类似，它们是读写锁的tryLock()的实际实现，表示尝试获取一次锁

1. tryWriteLock方法尝试获得写锁，先判断状态是否为0，为0并且CAS操作成功就表示获得锁。如果状态不为0，就判断写锁计数器的值，如果写锁计数器为0就表示存在读锁，就返回失败，获取写锁不为0，但是不是当前线程所获取的，也返回失败。只有写锁不为0并且是当前线程自己获取的写锁，就是所谓的写锁重入操作。CAS成功后就表示获得写锁

final boolean tryWriteLock() {
Thread current = Thread.currentThread();
int c = getState();
if (c != 0) {
int w = exclusiveCount(c);
if (w == 0 ||current != getExclusiveOwnerThread())
return false;
if (w == MAX_COUNT)
throw new Error("Maximum lock count exceeded");
}
if (!compareAndSetState(c, c + 1))
return false;
setExclusiveOwnerThread(current);
return true;
}
final boolean tryReadLock() {
Thread current = Thread.currentThread();
for (;;) {
int c = getState();
if (exclusiveCount(c) != 0 &&
getExclusiveOwnerThread() != current)
return false;
if (sharedCount(c) == MAX_COUNT)
throw new Error("Maximum lock count exceeded");
if (compareAndSetState(c, c + SHARED_UNIT)) {
HoldCounter rh = cachedHoldCounter;
if (rh == null || rh.tid != current.getId())
cachedHoldCounter = rh = readHolds.get();
rh.count++;
return true;
}
}
}

ReentrantReadWriteLock也提供了非公平和公平的两个Sync版本

非公平的版本中

1. 写锁总是优先获取，不考虑AQS队列中先来的线程

2. 读锁也不按FIFO队列排队，而是看当前获得锁是否是写锁，如果是写锁，就等待，否则就尝试获得锁

而公平版本中

1. 如果有其他锁存在，获取写锁操作就失败，应该(should)进AQS队列等待

2. 如果有其他锁存在，获取读锁操作就失败，应该(should)进AQS队列等待

final static class NonfairSync extends Sync {
private static final long serialVersionUID = -8159625535654395037L;
final boolean writerShouldBlock(Thread current) {
return false; // writers can always barge
}
final boolean readerShouldBlock(Thread current) {
/* As a heuristic to avoid indefinite writer starvation,
* block if the thread that momentarily appears to be head
* of queue, if one exists, is a waiting writer. This is
* only a probablistic effect since a new reader will not
* block if there is a waiting writer behind other enabled
* readers that have not yet drained from the queue.
*/
return apparentlyFirstQueuedIsExclusive();
}
}
/**
* Fair version of Sync
*/
final static class FairSync extends Sync {
private static final long serialVersionUID = -2274990926593161451L;
final boolean writerShouldBlock(Thread current) {
// only proceed if queue is empty or current thread at head
return !isFirst(current);
}
final boolean readerShouldBlock(Thread current) {
// only proceed if queue is empty or current thread at head
return !isFirst(current);
}
}

具体ReadLock和WriteLock的实现就是依赖Sync来实现的，默认是非公平版本的Sync。

读锁采用共享默认的AQS，它提供了中断/不可中断的lock操作，tryLock操作，限时的tryLock操作。值得注意的时读锁不支持newCondition操作。

public static class ReadLock implements Lock, java.io.Serializable {
private static final long serialVersionUID = -5992448646407690164L;
private final Sync sync;
protected ReadLock(ReentrantReadWriteLock lock) {
sync = lock.sync;
}
public void lock() {
sync.acquireShared(1);
}
public void lockInterruptibly() throws InterruptedException {
sync.acquireSharedInterruptibly(1);
}
public boolean tryLock() {
return sync.tryReadLock();
}
public boolean tryLock(long timeout, TimeUnit unit) throws InterruptedException {
return sync.tryAcquireSharedNanos(1, unit.toNanos(timeout));
}
public void unlock() {
sync.releaseShared(1);
}
public Condition newCondition() {
throw new UnsupportedOperationException();
}

WriteLock基于独占模式的AQS，它提供了中断/不可中断的lock操作，tryLock操作，限时的tryLock操作

public static class WriteLock implements Lock, java.io.Serializable {
private static final long serialVersionUID = -4992448646407690164L;
private final Sync sync;
protected WriteLock(ReentrantReadWriteLock lock) {
sync = lock.sync;
}
public void lock() {
sync.acquire(1);
}
public void lockInterruptibly() throws InterruptedException {
sync.acquireInterruptibly(1);
}
public boolean tryLock( ) {
return sync.tryWriteLock();
}
public boolean tryLock(long timeout, TimeUnit unit) throws InterruptedException {
return sync.tryAcquireNanos(1, unit.toNanos(timeout));
}
public void unlock() {
sync.release(1);
}
public Condition newCondition() {
return sync.newCondition();
}

最后再说一下AQS和各种同步器实现的关系，AQS提供了同步队列和条件队列的管理，包括各种情况下的入队出队操作。而同步器子类实现了tryAcquire和tryRelease方法来操作状态，来表示什么情况下可以直接获得锁而不需要进入AQS，什么情况下获取锁失败则需要进入AQS队列等待

聊聊高并发（二十八）解析java.util.concurrent各个组件（十）理解ReentrantReadWriteLock可重入读-写锁相关推荐

聊聊高并发（十七）解析java.util.concurrent各个组件（一）了解sun.misc.Unsafe类
了解了并发编程中锁的基本原理之后,接下来看看Java是如何利用这些原理来实现各种锁,原子变量,同步组件的.在开始分析java.util.concurrent的源代码直接,首先要了解的就是sun.mis ...
聊聊高并发（二十一）解析java.util.concurrent各个组件（三）深入理解AQS（一）
AQS是AbstractQueuedSynchronizer的缩写,AQS是Java并包里大部分同步器的基础构件,利用AQS可以很方便的创建锁和同步器.它封装了一个状态,提供了一系列的获取和释放操作, ...
聊聊高并发（二十）解析java.util.concurrent各个组件（二） 12个原子变量相关类
这篇说说java.util.concurrent.atomic包里的类,总共12个,网上有很多文章解析这几个类,这里挑些重点说说. 这12个类可以分为三组: 1. 普通类型的原子变量 2. 数组类型的 ...
聊聊高并发（三十）解析java.util.concurrent各个组件（十二）理解CyclicBarrier栅栏
这篇讲讲CyclicBarrier栅栏,从它的名字可以看出,它是可循环使用的.它的功能和CountDownLatch类似,也是让一组线程等待,然后一起开始往下执行.但是两者还是有几个区别 1. 等待的 ...
聊聊高并发（二十七）解析java.util.concurrent各个组件（九）理解ReentrantLock可重入锁
这篇讲讲ReentrantLock可重入锁,JUC里提供的可重入锁是基于AQS实现的阻塞式可重入锁.这篇聊聊高并发(十六)实现一个简单的可重入锁模拟了可重入锁的实现.可重入锁的特点是: 1. 是互 ...
聊聊高并发（二十三）解析java.util.concurrent各个组件（五）深入理解AQS（三）
这篇对AQS做一个总结. 上一篇帖了很多AQS的代码,可以看出AQS的实现思路很简单,就是提供了获取acquire和释放操作release,提供了 1. 可中断和不可中断的版本 2. 可定时和不可定时 ...
聊聊高并发（四十）解析java.util.concurrent各个组件（十六） ThreadPoolExecutor源码分析
ThreadPoolExecutor是Executor执行框架最重要的一个实现类,提供了线程池管理和任务管理是两个最基本的能力.这篇通过分析ThreadPoolExecutor的源码来看看如何设计和实 ...
聊聊高并发（二十九）解析java.util.concurrent各个组件（十一）再看看ReentrantReadWriteLock可重入读-写锁
上一篇聊聊高并发(二十八)解析java.util.concurrent各个组件(十) 理解ReentrantReadWriteLock可重入读-写锁讲了可重入读写锁的基本情况和主要的方法,显示了如何 ...
聊聊高并发（二十九）解析java.util.concurrent各个组件（十一）再看看ReentrantReadWriteLock可重入读-写锁...
上一篇聊聊高并发(二十八)解析java.util.concurrent各个组件(十) 理解ReentrantReadWriteLock可重入读-写锁讲了可重入读写锁的基本情况和基本的方法,显示了怎样 ...

聊聊高并发（二十八）解析java.util.concurrent各个组件（十）理解ReentrantReadWriteLock可重入读-写锁

聊聊高并发（二十八）解析java.util.concurrent各个组件（十）理解ReentrantReadWriteLock可重入读-写锁相关推荐

最新文章

热门文章

聊聊高并发（二十八）解析java.util.concurrent各个组件（十） 理解ReentrantReadWriteLock可重入读-写锁

聊聊高并发（二十八）解析java.util.concurrent各个组件（十） 理解ReentrantReadWriteLock可重入读-写锁相关推荐

最新文章

热门文章

聊聊高并发（二十八）解析java.util.concurrent各个组件（十）理解ReentrantReadWriteLock可重入读-写锁

聊聊高并发（二十八）解析java.util.concurrent各个组件（十）理解ReentrantReadWriteLock可重入读-写锁相关推荐