ReentrantLock实现了标准的互斥重入锁，任一时刻只有一个线程能获得锁。考虑这样一个场景：大部分时间都是读操作，写操作很少发生；我们知道，读操作是不会修改共享数据的，如果实现互斥锁，那么即使都是读操作，也只有一个线程能获得锁，其他的读都得阻塞。这样显然不利于提供系统的并发量。在JDK1.5中，Doug Lea又给我们带来了读写锁ReentrantReadWriteLock，在读-写锁的实现加锁策略中，允许多个读操作同时进行，但每次只允许一个写操作。
ReentrantReadWriteLock的结构
ReentrantReadWriteLock(简称RRWL)的实现也是通过AQS来实现的，它的内部也与一个Sync类，继承自AQS，读写锁都是依赖它来实现。在RRWL内部有两个类来分别实现读锁和写锁，ReadLock和WriteLock。RRWL有两个方法分别用于返回读锁和写锁：
ReentrantReadWriteLock.ReadLock | readLock()
返回读锁
|
ReentrantReadWriteLock.WriteLock | writeLock()
返回写锁
|
Sync类
在读写锁中最重要的就是Sync类，它继承自AQS，还记得吗，AQS使用一个int型来保存状态，状态在这里就代表锁，它提供了获取和修改状态的方法。可是，这里要实现读锁和写锁，只有一个状态怎么办？Doug Lea是这么做的，它把状态的高16位用作读锁，低16位用作写锁，所以无论是读锁还是写锁最多只能被持有65535次。所以在判断读锁和写锁的时候，需要进行位运算：
（1）由于读写锁共享状态，所以状态不为0，只能说明是有锁，可能是读锁，也可能是写锁；
（2）读锁是高16为表示的，所以读锁加1，就是状态的高16位加1，低16位不变，所以要加的不是1，而是2^16，减一同样是这样。
（3）写锁用低16位表示，要获得写锁的次数，要用状态&2^16-1，结果的高16位全为0，低16位就是写锁被持有的次数。
在Sync中还有几个属性，会在后面的代码中用到。
/** 实现ReentrantReadWriteLock的同步器，分别用子类来实现公平和非公平策略 */
abstract static class Sync extends AbstractQueuedSynchronizer {
private static final long serialVersionUID = 6317671515068378041L;
//最多支持65535个写锁和65535个读锁；低16位表示写锁计数，高16位表示持有读锁的线程数
static final int SHARED_SHIFT = 16;
//由于读锁用高位部分，读锁个数加1，其实是状态值加 2^16
static final int SHARED_UNIT = (1 << SHARED_SHIFT);
static final int MAX_COUNT = (1 << SHARED_SHIFT) - 1;
/**写锁的掩码，用于状态的低16位有效值 */
static final int EXCLUSIVE_MASK = (1 << SHARED_SHIFT) - 1;
/** 读锁计数，当前持有读锁的线程数，c的高16位 */
static int sharedCount(int c) { return c >>> SHARED_SHIFT; }
/** 写锁的计数，也就是它的重入次数,c的低16位*/
static int exclusiveCount(int c) { return c & EXCLUSIVE_MASK; }
/**
* 每个线程持有读锁的计数
*/
static final class HoldCounter {
int count = 0;
//使用id而不是引用是为了避免保留垃圾。注意这是个常量。
final long tid = Thread.currentThread().getId();
}
/**
* 采用继承是为了重写 initialValue 方法，这样就不用进行这样的处理：
* 如果ThreadLocal没有当前线程的计数，则new一个，再放进ThreadLocal里。
* 可以直接调用 get。
* */
static final class ThreadLocalHoldCounter
extends ThreadLocal<HoldCounter> {
public HoldCounter initialValue() {
return new HoldCounter();
}
}
/**
* 当前线程持有的可重入读锁的数量，仅在构造方法和readObject(反序列化)
* 时被初始化，当持有锁的数量为0时，移除此对象。
*/
private transient ThreadLocalHoldCounter readHolds;
/**
* 最近一个成功获取读锁的线程的计数。这省却了ThreadLocal查找，
* 通常情况下，下一个释放线程是最后一个获取线程。这不是 volatile 的，
* 因为它仅用于试探的，线程进行缓存也是可以的
* （因为判断是否是当前线程是通过线程id来比较的）。
*/
private transient HoldCounter cachedHoldCounter;
/**firstReader是第一个获得读锁的线程；
* firstReaderHoldCount是firstReader的重入计数；
* 更准确的说，firstReader是最后一个把共享计数从0改为1，并且还没有释放锁。
* 如果没有这样的线程，firstReader为null;
* firstReader不会导致垃圾堆积，因为在tryReleaseShared中将它置空了，除非
* 线程异常终止，没有释放读锁。
*
* 跟踪无竞争的读锁计数时，代价很低
*/
private transient Thread firstReader = null;
private transient int firstReaderHoldCount;
Sync() {
readHolds = new ThreadLocalHoldCounter();
setState(getState()); // ensures visibility of readHolds
}final boolean writerShouldBlock()；//写锁是否需要阻塞
final boolean readerShouldBlock()；//读锁是否需要阻塞
获取读锁
读锁是共享锁，同一时刻可以被多个线程获得，下面是获得读锁的代码：
/**
* 获取读锁，如果写锁不是由其他线程持有，则获取并立即返回；
* 如果写锁被其他线程持有，阻塞，直到读锁被获得。
*/
public void lock() {
sync.acquireShared(1);
}
//ASQ的acquireShared
/**
* 以共享模式获取对象，忽略中断。通过至少先调用一次 tryAcquireShared(int)
* 来实现此方法，并在成功时返回。否则在成功之前，一直调用 tryAcquireShared(int)
* 将线程加入队列，线程可能重复被阻塞或不被阻塞。
*/
public final void acquireShared(int arg) {
if (tryAcquireShared(arg) < 0)
doAcquireShared(arg);
}
//Sync中的tryAcquireShared
protected final int tryAcquireShared(int unused) {
Thread current = Thread.currentThread();
int c = getState();
//持有写锁的线程可以获得读锁
if (exclusiveCount(c) != 0 &&
getExclusiveOwnerThread() != current)
return -1;//写锁被占用，且不是由当前线程持有，返回-1
//执行到这里表明：写锁可用，或者写锁由当前线程持有
//获得读锁的数量
int r = sharedCount(c);
/** 如果不用阻塞，且没有溢出，则使用CAS修改状态，并且修改成功 */
if (!readerShouldBlock() &&
r < MAX_COUNT &&
compareAndSetState(c, c + SHARED_UNIT)) {//修改高16位的状态，所以要加上2^16
//这是第一个占有读锁的线程，设置firstReader
if (r == 0) {
firstReader = current;
firstReaderHoldCount = 1;
} else if (firstReader == current) {//重入计数加1
firstReaderHoldCount++;
} else {
// 非 firstReader 读锁重入计数更新
//将cachedHoldCounter设置为当前线程
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);
}
（1）如果当前写锁被其他线程持有，则获取读锁失败；
（2）写锁空闲，或者写锁被当前线程持有（写锁可降级为读锁），在公平策略下，它可能需要阻塞，那么tryAcquireShared()就可能失败，则需要进入队列等待；如果是非公平策略，会尝试获取锁，使用CAS修改状态，修改成功，则获得读锁，否则也会进入同步队列等待；
（3）进入同步队列后，就是由AQS来完成唤醒。
释放读锁
一般来说，释放锁比获取锁要容易一些，看一下释放读锁的代码：
protected final boolean tryReleaseShared(int unused) {
//将当前线程的读锁计数器的值减1
Thread current = Thread.currentThread();
/**
* 当前线程是第一个获取到锁的，如果此线程要释放锁了，则firstReader置空
* 否则，将线程持有的锁计数减1
*/
if (firstReader == current) {
// assert firstReaderHoldCount > 0;
if (firstReaderHoldCount == 1)
firstReader = null;
else
firstReaderHoldCount--;
} else {
HoldCounter rh = cachedHoldCounter;
//如果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;//高16位-1
if (compareAndSetState(c, nextc))
// 释放读锁对其他读线程没有任何影响，
// 但可以允许等待的写线程继续，如果读锁、写锁都空闲。
return nextc == 0;
}
}写锁的获取
protected final boolean tryAcquire(int acquires) {
Thread current = Thread.currentThread();
//获取状态，是读写锁共有的
int c = getState();
//写锁被持有的次数，通过与低16位做与操作得到
int w = exclusiveCount(c);
//c!=0，说明存在锁，可能是读锁，也可能是写锁
if (c != 0) {
// c!=0,w==0,说明读锁存在
//w != 0 && current != getExclusiveOwnerThread() 表示其他线程获取了写锁。
if (w == 0 || current != getExclusiveOwnerThread())
return false;
//如果超过了最大限制，则抛出异常
if (w + exclusiveCount(acquires) > MAX_COUNT)
throw new Error("Maximum lock count exceeded");
//执行到这里，说明存在写锁，且由当前线程持有
// 重入计数
setState(c + acquires);
return true;
}
//执行到这里，说明不存在任何锁
//WriterShouldBlock留给子类实现公平策略
//使用CAS修改状态
if (writerShouldBlock() ||
!compareAndSetState(c, c + acquires))
return false;
setExclusiveOwnerThread(current);
return true;
}（1）首先获得状态，保存到c中，获得写锁的计数保存到w中；这个时候需要根据c的值来判断是否存在锁
（2）如果c!=0，说明存在锁，如果w==0，说明存在读锁，获取写锁不能成功；如果w!=0，但是写锁是由其他线程持有的，那么当前线程获取写锁也不能成功；在这种情况下（存在写锁），只有写锁是由当前线程持有的，才能获得成功；
（3）如果c==0，说明不存在锁，如果是公平策略，还需要进入同步队列；如果是非公平策略，会尝试获得写锁。
释放写锁
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;
}上面只是简单的介绍了ReentrantReadWriteLock的实现，过会还会补充。
转载请注明：喻红叶《Java并发-ReentrantReadWriteLock源码分析》
扫一扫
342
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
