深夜！小胖问我什么是读写锁？插队策略？升降级？（上）

读锁 & 写锁

来到多线程的第十二篇，前十一篇请点文末底部的上、下一篇标签。这篇聊聊读写锁。什么是读锁 & 写锁？开篇之前先聊聊这小两口的定义：

从上图可以看见，读锁 & 写锁和 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 运行完毕，想插队的读线程才有机会运行，这样谁都不会等待太久的时间」。