深夜！小胖问我什么是读写锁？插队策略？升降级？
读锁 & 写锁
来到多线程的第十二篇，前十一篇请点文末底部的上、下一篇标签。这篇聊聊读写锁。什么是读锁 & 写锁？开篇之前先聊聊这小两口的定义：
继承关系
内部类
从上图可以看见，读锁 & 写锁和 ReentrantLock 一样都是实现了 Lock 接口，并且它两还是 ReentrantReadWriteLock 类的内部类。
- 写锁也叫独占锁，它既能读取数据也能修改数据，同一时间只能有一个线程持有，它是非线程安全的
- 读锁也叫共享锁，它只能读取数据，允许多个线程同时持有，它是线程安全的
为什么要有读写锁？
回答这个问题之前，试着想象这样一个场景：在没有读写锁的情况下。我们用 ReentrantLock 仍然是可以保证线程安全的，但同时也浪费了资源。因为读操作是线程安全的，我们允许让多个读操作并行，以便提高程序效率。
但是「写操作不是线程安全的」，如果多个线程同时写，或者在写的同时进行读操作，便会造成线程安全问题。
所以，「在读的地方合理使用读锁，在写的地方合理使用写锁，灵活控制，可以提高程序的执行效率」。
获取读写锁的规则
看完以上之后，在使用读写锁时遵守下面的 3 个规则：
- 1、有一个线程已经占用了读锁，则此时其他线程如果要申请读锁，可以申请成功。
- 2、有一个线程已经占用了读锁，则此时其他线程如果要申请写锁，则申请写锁的线程会一直等待释放读锁，因为读写不能同时操作。
- 3、有一个线程已经占用了写锁，则此时其他线程如果申请写锁或者读锁，都必须等待之前的线程释放写锁，同样也因为读写不能同时，并且两个线程不应该同时写。
一句话总结：要么是一个或多个线程同时有读锁，要么是一个线程有写锁，但是两者不会同时出现。也可以总结为：「读读共享、其他都互斥（写写互斥、读写互斥、写读互斥）」。
如何使用？
/**
* 读写锁用法
*/
public class ReadWriteLockDemo {
private static final ReentrantReadWriteLock reentrantReadWriteLock = new ReentrantReadWriteLock(false);
private static final ReentrantReadWriteLock.ReadLock readLock = reentrantReadWriteLock.readLock();
private static final ReentrantReadWriteLock.WriteLock writeLock = reentrantReadWriteLock.writeLock();
private static void read() {
readLock.lock();
try {
System.out.println(Thread.currentThread().getName() + "得到读锁，正在读取");
Thread.sleep(500);
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
System.out.println(Thread.currentThread().getName() + "释放读锁");
readLock.unlock();
}
}
private static void write() {
writeLock.lock();
try {
System.out.println(Thread.currentThread().getName() + "得到写锁，正在写入");
Thread.sleep(500);
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
System.out.println(Thread.currentThread().getName() + "释放写锁");
writeLock.unlock();
}
}
public static void main(String[] args) throws InterruptedException {
// 两个线程获取读锁
new Thread(ReadWriteLockDemo::read).start();
new Thread(ReadWriteLockDemo::read).start();
// 两个线程获取写锁
new Thread(ReadWriteLockDemo::write).start();
new Thread(ReadWriteLockDemo::write).start();
}
}
运行结果：
运行结果
从运行结果可以看出，读锁可以同时被多个线程获得，而写锁不能。
非公平下的读锁应该插队吗？
首先读写锁也是可以设置公平非公平的。具体可以这样设置：「公平锁在构造传入 true，否则传 false。啥也不传，默认的是非公平锁」。
// 读写锁（公平）
ReentrantReadWriteLock reentrantReadWriteLock = new ReentrantReadWriteLock(true);
// 读写锁（非公平）
ReentrantReadWriteLock reentrantReadWriteLock = new ReentrantReadWriteLock(false);
上一篇聊公平锁 & 非公平锁的时候说过非公平的 ReentrantLock 在释放锁的瞬间是可以被插队的。那这个策略在读写锁这边也是一样的么？这个问题就得看源码了，「我发现不管是公平还是非公平在获取读锁的时候，线程会检查 readerShouldBlock () 方法，同样，在获取写锁之前，线程会检查 writerShouldBlock () 方法，来决定是否需要插队或者是去排队」。
首先是公平的情况下，两者都会调用 hasQueuedPredecessors 方法，这个方法还熟悉么？「它的作用就是判断当前线程是否在队首（是否需要排队）」。也就是「只有当前线程是队首，不需要排队。返回 false 的时候才能获取锁，这很公平」。
读写锁（公平）
然后看看不公平的情况，对于想获取写锁的线程而言，由于返回值一直是 false，所以它是随时可以插队的。
读写锁（不公平）
而读锁的情况就有点复杂了，复杂到我不得不画几个图帮你们理解下。首先介绍下场景：4 个线程，他们的名字分别叫狗哥（读线程 1）、渣男小钊（读线程 2）、原谅绿小民（读线程 3）以及一个写线程 1。
现在狗哥和小钊两个读线程同时读取，写线程 1 想要写入，但是由于已经有两个读线程持有锁了，只能去队列等待。这时，小民这个读线程想插队获取读锁。
帅比狗哥
这种情况有两种策略：
- 1、允许插队
由于读锁的线程安全的，多个同时操作也没问题，不增加负担。所以第一种策略就让小民（读线程 3）直接加入到狗哥（读线程 1）和小钊（读线程 2）一起去读取。
但是这会有问题呀。「要是这时又有另一个名叫海王小宝的读线程 4 过来插队，这就会导致读锁长时间内不会被释放，导致写线程 1 长时间内拿不到写锁，也就是那个需要拿到写锁的线程会陷入 "饥饿" 状态，严重点还会饿死」。
渣男小钊
- 2、不允许插队
这种策略认为由于写线程 1 已经提前等待了，所以虽然剩下的读线程直接插队成功，可以提高效率，但是我们依然让读线程去排队等待。
海王小宝
这种策略的话，「想插队的读线程都会被放入等待队列中，并且排在写线程 1 的后面，让写线程 1 优先于插队的读线程执行，就可以避免 "饥饿" 状态，直到写线程 1 运行完毕，想插队的读线程才有机会运行，这样谁都不会等待太久的时间」。
原谅绿小民
「而我们的读写锁（非公平）就是采用第二种策略，只要等待队列的头结点是尝试获取写锁的线程，那么读锁依然是不能插队的，目的是避免 "饥饿"」。
策略选择演示
口说无凭不写代码的行为简直不讲码德。还是得写代码演示下上述流程图的结论：
/**
* 读写锁（非公平），读锁不插队
*/
public class ReadLockJumpQueue {
private static final ReentrantReadWriteLock reentrantReadWriteLock = new ReentrantReadWriteLock();
private static final ReentrantReadWriteLock.ReadLock readLock = reentrantReadWriteLock.readLock();
private static final ReentrantReadWriteLock.WriteLock writeLock = reentrantReadWriteLock.writeLock();
private static void read() {
readLock.lock();
try {
System.out.println(Thread.currentThread().getName() + "得到读锁，正在读取");
Thread.sleep(2000);
} catch (InterruptedException e) { e.printStackTrace();
} finally {
System.out.println(Thread.currentThread().getName() + "释放读锁");
readLock.unlock();
}
}
private static void write() {
writeLock.lock();
try {
System.out.println(Thread.currentThread().getName() + "得到写锁，正在写入");
Thread.sleep(2000);
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
System.out.println(Thread.currentThread().getName() + "释放写锁");
writeLock.unlock();
}
}
public static void main(String[] args) throws InterruptedException {
new Thread(ReadLockJumpQueue::read, "帅比狗哥").start();
Thread.sleep(100);
new Thread(ReadLockJumpQueue::read, "渣男小钊").start();
Thread.sleep(100);
new Thread(ReadLockJumpQueue::write, "写线程1").start();
Thread.sleep(100);
new Thread(ReadLockJumpQueue::read, "海王小宝").start();
}
}
从这个结果可以看出，不公平下的读锁选择了不允许插队的策略，从而很大程度上减小了发生 "饥饿" 的概率.
运行结果
什么是读写锁的升降级？
先看段代码。代码演示的是在更新缓存的时候，如何使用读写锁的升降级。
/**
* 更新缓存演示锁降级
*/
public class CachedData {
Object data;
volatile boolean cacheValid;
final ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();
void processCachedData() {
rwl.readLock().lock();
if (!cacheValid) {
//在获取写锁之前，必须首先释放读锁。
rwl.readLock().unlock();
rwl.writeLock().lock();
try {
// 这里需要再次判断数据的有效性
// 因为在我们释放读锁和获取写锁的空隙之内，可能有其他线程修改了数据。
if (!cacheValid) {
data = new Object();
cacheValid = true;
}
//在不释放写锁的情况下，直接获取读锁，这就是读写锁的降级。
rwl.readLock().lock();
} finally {
//释放了写锁，但是依然持有读锁
rwl.writeLock().unlock();
}
}
try {
System.out.println(data);
} finally {
//释放读锁
rwl.readLock().unlock();
}
}
}
先看看程序，注释写得很清楚了。大概的流程就是先获取读锁读缓存，再释放读锁获取写锁，写锁修改缓存。然后重点来了，「线程在不释放写锁的情况下，获取读锁（这就是锁的降级）」，然后释放写锁。读锁读取数据，最后释放读锁。
「PS：由于写锁是独占锁，当前线程获取写锁之后，其它线程就既不能获取写锁也不能获取读锁了，但是当前已经获取写锁的线程仍然可以获取读锁」。
为什么需要锁的降级？
你可能会说，写锁既能修改、又能读取。那直接用写锁就好了呀。干嘛要降级？其实不然，仔细看刚刚的代码：
data = new Object();
只有这一句是写的操作。如果这个线程一直用写锁，那其他线程在这段时间就无法获取锁操作了。浪费资源、降低了效率。「所以针对读多，写非常少的任务，还是用锁的降级比较明智」。
只支持降级，不支持升级
运行下面这段代码，「在不释放读锁的情况下直接尝试获取写锁，也就是锁的升级，会让线程直接阻塞，程序是无法运行的」。
final static ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();
public static void main(String[] args) {
upgrade();
}
public static void upgrade() {
rwl.readLock().lock();
System.out.println("获取到了读锁");
rwl.writeLock().lock();
System.out.println("成功升级");
}
为什么不支持锁的升级？
读写锁的特点是如果线程都申请读锁，是可以多个线程同时持有的，可是如果是写锁，只能有一个线程持有，并且不可能存在读锁和写锁同时持有的情况。
举个栗子：假设线程 A 和 B 都想升级到写锁，那么对于线程 A 而言，它需要等待其他所有线程，包括线程 B 在内释放读锁。而线程 B 也需要等待所有的线程，包括线程 A 释放读锁。这就是一种非常典型的死锁的情况。谁都愿不愿意率先释放掉自己手中的锁。
一句话总结就是「多个线程同时发生锁升级的时候，会发生死锁，因为发生锁升级的线程会等待其它线程释放读锁」。
总结
1、定义
- 写锁也叫独占锁，它既能读取数据也能修改数据，同一时间只能有一个线程持有，它是非线程安全的
- 读锁也叫共享锁，它只能读取数据，允许多个线程同时持有，它是线程安全的
2、为什么？
- 读写锁的出现可以提高程序的执行效率
3、加锁规则
读读共享、其他都互斥（写写互斥、读写互斥、写读互斥）
4、插队策略
- 公平策略下，只要队列里有线程已经在排队，就不允许插队。
非公平策略下：
- 为了防止 “饥饿”，在等待队列的头结点是尝试获取写锁的线程的时候，不允许读锁插队。
- 写锁可以随时插队，因为写锁并不容易插队成功，写锁只有在当前没有任何其他线程持有读锁和写锁的时候，才能插队成功，同时写锁一旦插队失败就会进入等待队列，所以很难造成 “饥饿” 的情况，允许写锁插队是为了提高效率。
5、升降级策略
- 升降级策略：只能从写锁降级为读锁，不能从读锁升级为写锁。
巨人的肩膀
- https://kaiwu.lagou.com/course/courseInfo.htm?courseId=16#/detail/pc?id=265
腾讯云开发者
