【1】基本讲解与使用
ReadWriteLock同Lock一样也是一个接口，提供了readLock和writeLock两种锁的操作机制，一个是只读的锁，一个是写锁。
读锁可以在没有写锁的时候被多个线程同时持有，写锁是独占的。 每次只能有一个写线程，但是可以有多个线程并发地读数据。
所有读写锁的实现必须确保写操作对读操作的内存影响。换句话说，一个获得了读锁的线程必须能看到前一个释放的写锁所更新的内容。
理论上，读写锁比互斥锁允许对于共享数据更大程度的并发。与互斥锁相比，读写锁是否能够提高性能取决于读写数据的频率、读取和写入操作的持续时间、以及读线程和写线程之间的竞争。
使用场景
假设你的程序中涉及到对一些共享资源的读和写操作，且写操作没有读操作那么频繁。
例如，最初填充有数据，然后很少修改的集合，同时频繁搜索（例如某种目录）是使用读写锁的理想候选项。
在没有写操作的时候，两个线程同时读一个资源没有任何问题，所以应该允许多个线程能在同时读取共享资源。但是如果有一个线程想去写这些共享资源，就不应该再有其它线程对该资源进行读或写。这就需要一个读/写锁来解决这个问题。
互斥原则：
- 读-读能共存，
- 读-写不能共存，
- 写-写不能共存。
ReadWriteLock 接口源码示例
public interface ReadWriteLock {
/**
* Returns the lock used for reading.
*/
Lock readLock();
/**
* Returns the lock used for writing.
*/
Lock writeLock();
}
使用示例
实例代码如下：
public class TestReadWriteLock {
public static void main(String[] args){
ReadWriteLockDemo rwd = new ReadWriteLockDemo();
//启动100个读线程
for (int i = 0; i < 100; i++) {
new Thread(new Runnable() {
@Override
public void run() {
rwd.get();
}
}).start();
}
//写线程
new Thread(new Runnable() {
@Override
public void run() {
rwd.set((int)(Math.random()*101));
}
},"Write").start();
}
}
class ReadWriteLockDemo{
//模拟共享资源--Number
private int number = 0;
private ReadWriteLock readWriteLock = new ReentrantReadWriteLock();
//读
public void get(){
readWriteLock.readLock().lock();
try {
System.out.println(Thread.currentThread().getName()+" : "+number);
}finally {
readWriteLock.readLock().unlock();
}
}
//写
public void set(int number){
readWriteLock.writeLock().lock();
try {
this.number = number;
System.out.println(Thread.currentThread().getName()+" : "+number);
}finally {
readWriteLock.writeLock().unlock();
}
}
}
测试结果如下图：
首先启动读线程，此时number为0；然后写线程修改了共享资源number数据，读线程再次读取最新值！
【2】ReentrantReadWriteLock源码分析
ReentrantReadWriteLock是ReadWriteLock接口的实现类–可重入的读写锁。
① ReentrantReadWriteLock拥有的特性
- 1.1获取顺序(公平和非公平)
ReentrantReadWriteLock不会为锁定访问强加读或者写偏向顺序，但是它确实是支持可选的公平策略。
-
- 非公平模式(默认)
构造为非公平策略（缺省值）时，读写锁的入口顺序未指定，这取决于可重入性约束。持续竞争的非公平锁可以无限期地延迟一个或多个读写器线程，但通常具有比公平锁更高的吞吐量。
-
- 公平模式
当构造为公平策略时，线程使用近似的到达顺序策略(队列策略)争夺输入。当释放当前持有的锁时，要么最长等待的单个写入线程将被分配写锁，或者如果有一组读取线程等待的时间比所有等待的写入线程都长，那么该组读线程组将被分配读锁。
如果写入锁被占有，或者存在等待写入线程，则试图获取公平读取锁（非可重入）的线程将阻塞。直到当前等待写入线程中最老的线程获取并释放写入锁之后，该线程才会获取读取锁。当然，如果等待的写入线程放弃等待，剩下一个或多个读取器线程作为队列中最长的等待器而没有写锁，那么这些读取器将被分配读锁。
试图获得公平写锁（非可重入）的线程将阻塞，除非读锁和写锁都是空闲的（这意味着没有等待的线程）。（请注意，非阻塞 ReadLock#tryLock()和{@link WriteLock#tryLock()方法不遵守此公平策略设置，并且如果可能的话将立即获取锁，而不管等待的线程）。
-
- 构造器源码如下：
/**
* Creates a new {@code ReentrantReadWriteLock} with
* default (nonfair) ordering properties.
*/
public ReentrantReadWriteLock() {
this(false);
}
/**
* Creates a new {@code ReentrantReadWriteLock} with
* the given fairness policy.
*
* @param fair {@code true} if this lock should use a fair ordering policy
*/
public ReentrantReadWriteLock(boolean fair) {
sync = fair ? new FairSync() : new NonfairSync();
readerLock = new ReadLock(this);
writerLock = new WriteLock(this);
}
可以看到，默认的构造方法使用的是非公平模式，创建的Sync是NonfairSync对象，然后初始化读锁和写锁。一旦初始化后，ReadWriteLock接口中的两个方法就有返回值了，如下：
public ReentrantReadWriteLock.WriteLock writeLock() { return writerLock; }
public ReentrantReadWriteLock.ReadLock readLock() { return readerLock; }
- 1.2可重入
这个锁允许读线程和写线程以ReentrantLock的语法重新获取读写锁。在写入线程保持的所有写入锁被释放之前，不允许不可重入的读线程。
另外，写锁(写线程)可以获取读锁，但是不允许读锁(读线程)获取写锁。在其他应用程序中，当对在读锁下执行读取的方法或回调期间保持写锁时，可重入性可能非常有用。
- 1.3锁降级
可重入特性还允许从写锁降级到读锁—通过获取写锁，然后获取读锁，然后释放写锁。但是，从读锁到写锁的升级是不可能的。
- 1.4锁获取的中断
在读锁和写锁的获取过程中支持中断 。
- 1.5支持Condition
Condition详解参考：Condition与Lock使用详解。
写锁提供了Condition实现，ReentrantLock.newCondition;读锁不支持Condition。
- 1.6监控
该类支持确定锁是否持有或争用的方法。这些方法是为了监视系统状态而设计的，而不是用于同步控制。
② 特性使用实例
- 2.1锁降级
class CachedData {
Object data;
//volatile修饰，保持内存可见性
volatile boolean cacheValid;
//可重入读写锁
final ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();
void processCachedData() {
//首先获取读锁
rwl.readLock().lock();
//发现没有缓存数据则放弃读锁，获取写锁
if (!cacheValid) {
// Must release read lock before acquiring write lock
rwl.readLock().unlock();
rwl.writeLock().lock();
try {
// Recheck state because another thread might have
// acquired write lock and changed state before we did.
if (!cacheValid) {
data = ...
cacheValid = true;
}
// Downgrade by acquiring read lock before releasing write lock
rwl.readLock().lock();
} finally {
//进行锁降级
rwl.writeLock().unlock();
// Unlock write, still hold read
}
}
try {
use(data);
} finally {
rwl.readLock().unlock();
}
}
}}
- 2.2集合使用场景
通常可以在集合使用场景中看到ReentrantReadWriteLock的身影。不过只有在集合比较大，读操作比写操作多，操作开销大于同步开销的时候才是值得的。
实例如下：
class RWDictionary {
//集合对象
private final Map<String, Data> m = new TreeMap<String, Data>();
//读写锁
private final ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();
//获取读锁
private final Lock r = rwl.readLock();
//获取写锁
private final Lock w = rwl.writeLock();
public Data get(String key) {
r.lock();
try { return m.get(key); }
finally { r.unlock(); }
}
public String[] allKeys() {
r.lock();
try { return m.keySet().toArray(); }
finally { r.unlock(); }
}
public Data put(String key, Data value) {
w.lock();
try { return m.put(key, value); }
finally { w.unlock(); }
}
public void clear() {
w.lock();
try { m.clear(); }
finally { w.unlock(); }
}
}}
【3】Sync、FairSync和NonfairSync
再次回顾ReentrantReadWriteLock构造方法：
public ReentrantReadWriteLock(boolean fair) {
sync = fair ? new FairSync() : new NonfairSync();
readerLock = new ReadLock(this);
writerLock = new WriteLock(this);
}
从上面可以看到，构造方法决定了Sync是FairSync还是NonfairSync。Sync继承了AbstractQueuedSynchronizer，而Sync是一个抽象类，NonfairSync和FairSync继承了Sync，并重写了其中的抽象方法。
① Sync的两个抽象方法
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();
writerShouldBlock和readerShouldBlock方法都表示当有别的线程也在尝试获取锁时，是否应该阻塞。
FairSync类：
static final class FairSync extends Sync {
private static final long serialVersionUID = -2274990926593161451L;
final boolean writerShouldBlock() {
return hasQueuedPredecessors();
}
final boolean readerShouldBlock() {
return hasQueuedPredecessors();
}
}
对于公平模式，hasQueuedPredecessors()方法表示前面是否有等待线程。一旦前面有等待线程，那么为了遵循公平，当前线程也就应该被挂起。
NonfairSync 类：
static final class NonfairSync extends Sync {
private static final long serialVersionUID = -8159625535654395037L;
final boolean writerShouldBlock() {
return false; // writers can always barge
}
final boolean readerShouldBlock() {
/* 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 probabilistic 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();
}
}
从上面可以看到，非公平模式下，writerShouldBlock直接返回false，说明不需要阻塞。而readShouldBlock调用了apparentFirstQueuedIsExcluisve()方法。该方法在当前线程是写锁占用的线程时，返回true，否则返回false。即，如果当前有一个写线程正在写，那么该读线程应该阻塞。