悲观锁ReentrantLock ReentrantReadWriteLock VS 乐观锁Stampedlock

前言

在JDK的J.U.C包中，提供了丰富类型的锁（Lock）的能力，它们均实现了Lock接口，并扩展了不同类型的锁的实现，其中我们比较常见的锁有ReentrantLock、ReentrantReadWriteLock、StampedLock，本篇，我们就对这三种类型的锁进行横向比较，来分析其各自的特性，可以帮助您来根据场景来准确的判断，如何正确的来使用它们。

相关实现可以参见：

聊聊并发：（九）concurrent包之ReentrantLock分析
聊聊并发：（十）concurrent包之ReentrantReadWriteLock分析

ReentrantLock

ReentrantLock是一个独占型的可重入锁，是我们开发并发程序中比较常用的一种锁，它支持重入性，表示能够对共享资源能够重复加锁，即当前线程获取该锁再次获取不会被阻塞。

ReentrantLock经常拿来与synchronized关键字来进行对比，synchronized的锁也是支持可重入的，只不过synchronized的可重入性是基于Java语言的实现机制实现，ReentrantLock是基于代码层面进行的实现。

与synchronized类似，ReentrantLock也是一个独占锁，即当一个线程获取了锁的资源，其他线程请求锁资源时，会进行阻塞，直到占有锁资源的线程将其释放，其他线程才可以进行锁的抢夺。

但是在实际的互联网业务场景下，往往很多场景都是属于读多写少的场景，在高并发的场景下，可能会存在十个线程同时抢夺锁资源，其中七个线程是请求读，三个线程是请求写，但是当一个读的线程争抢到锁的资源后，其他六个读的线程，就必须进入同步队列等待锁资源（AQS队列），这样的话会大大降低并发度，同时也会造成一定的资源的浪费。

那么，针对这种读多写少的场景，是否有合适的锁类型呢？

ReentrantReadWriteLock

针对上一段中所说的，针对多读写少的场景下，锁资源抢夺的“痛点”，J.U.C中提供了另一种锁的实现——ReentrantReadWriteLock。

ReentrantReadWriteLock允许同一时刻被多个读线程访问，但是在写线程访问时，所有的读线程和其他的写线程都会被阻塞。

ReentrantReadWriteLock在内部实现了两种锁的类型，分别为读锁和写锁。同时，它也是一个支持可重入的锁，当持有读锁的线程获取后能再次获取同一把锁，写锁获取之后能够再次获取写锁，同时也能够获取读锁，但是反之则不可以，即持有读锁的线程，不可以再次获取写锁。

针对读多写少的场景，ReentrantReadWriteLock是非常的适合，当写锁未被占有时，可以支持多个线程获取读锁资源，以此来大幅度提高并发度。

但是ReentrantReadWriteLock的使用需要注意的一点是，写锁与读锁的降级策略，需要遵循获取写锁，获取读锁再释放写锁的次序，写锁能够降级成为读锁，但是反之不可以，即读锁不可以升级为写锁。

通过我们的分析可看出，会发现ReentrantReadWriteLock有个潜在的问题：如果有线程正在读，写线程需要等待读线程释放锁后才能获取写锁，即读的过程中不允许写，这是一种悲观的读锁。

那么问题来了，要进一步提升并发执行效率，是否有更加优化策略的锁实现呢？

StampedLock

在JDK1.8中，J.U.C中为了进一步提升锁的效率，引入了新的读写锁：StampedLock。

相比较于ReentrantReadWriteLock而言，改进之处在于：读的过程中也允许获取写锁后写入，如此，读取的数据就可能不一致，所以，需要一点额外的代码来判断读的过程中是否有写入，这种读锁是一种乐观读锁。

乐观锁的意思就是乐观地估计读的过程中大概率不会有写入，因此被称为乐观锁。反过来，悲观锁则是读的过程中拒绝有写入，也就是写入必须等待。显然乐观锁的并发效率更高，但一旦有小概率的写入导致读取的数据不一致，需要能检测出来，再读一遍就行。

StampedLock支持三种模式的锁：

1、写锁writeLock，当一个线程获取该锁后，其它请求的线程必须等待；

2、悲观读锁readLock，与ReentrantReadWriteLock功能类型，在没有线程获取独占写锁的情况下，同时多个线程可以获取该锁，如果已经有线程持有写锁，其他线程请求获取该读锁会被阻塞。

3、乐观读锁tryOptimisticRead，是相对于悲观锁来说的，如果当前没有线程持有写锁，则简单的返回一个非0的stamp版本信息，获取该stamp后在具体操作数据前还需要调用validate验证下该stamp是否已经不可用，也就是看当调用tryOptimisticRead返回stamp后到到当前时间间是否有其他线程持有了写锁，如果是那么validate会返回0，否者就可以使用该stamp版本的锁对数据进行操作。

我们来看一下JDK源码中对于StampedLock的使用方式给出的demo：

class Point {

    private double x, y;

    private final StampedLock sl = new StampedLock();

    void move(double deltaX, double deltaY) { // an exclusively locked method
        // 获取写锁
        long stamp = sl.writeLock();
        try {
            x += deltaX;
            y += deltaY;
        } finally {
            sl.unlockWrite(stamp);
        }
    }

    double distanceFromOrigin() { // A read-only method
        // 获取乐观读锁
        long stamp = sl.tryOptimisticRead();
        double currentX = x, currentY = y;
        // 检查乐观读锁后是否有其他写锁发生
        if (!sl.validate(stamp)) {
            // 乐观锁加成失败，重新获取读锁
            stamp = sl.readLock();
            try {
                currentX = x;
                currentY = y;
            } finally {
                sl.unlockRead(stamp);
            }
        }
        return Math.sqrt(currentX * currentX + currentY * currentY);
    }

    void moveIfAtOrigin(double newX, double newY) { // upgrade
        // Could instead start with optimistic, not read mode
        // 获取读锁
        long stamp = sl.readLock();
        try {
            while (x == 0.0 && y == 0.0) {
                // 尝试升级为写锁
                long ws = sl.tryConvertToWriteLock(stamp);
                // 如果失败，返回0
                if (ws != 0L) {
                    stamp = ws;
                    x = newX;
                    y = newY;
                    break;
                } else {
                    sl.unlockRead(stamp);
                    stamp = sl.writeLock();
                }
            }
        } finally {
            sl.unlock(stamp);
        }
    }
}

StampedLock的写锁获取与其他两种锁没有区别，核心点在于读锁的获取。

StampedLock提供了tryOptimisticRead方法来获取一个乐观锁，并返回一个版本号。该版本号用于validate方法，以此来验证版本号。

如果在读取过程中没有写入，版本号不变，验证成功，我们就可以放心地继续后续操作。如果在读取过程中有写入，版本号会发生变化，验证将失败。在失败的时候，我们再通过获取悲观读锁再次读取。

由于写入的概率不高，程序在绝大部分情况下可以通过乐观读锁获取数据，极少数情况下使用悲观读锁获取数据。

相比于ReentrantReadWriteLock，StampedLock同时支持了锁的升级，可以由读锁升级为写锁，通过tryConvertToWriteLock方法将读锁升级为写锁，如果当前写锁可用，则释放掉读锁获取写锁，并返回标记。

可见，StampedLock把读锁细分为乐观读和悲观读，能进一步提升并发效率。

但这也是有代价的：一是代码更加复杂，二是StampedLock是不可重入锁，不能在一个线程中反复获取同一个锁。

ReentrantLock VS ReentrantReadWriteLock VS StampedLock

上面，我们对JDK1.8中J.U.C中支持的三种锁的实现进行了简单介绍，下面我们就对这三种类型的锁进行一下简单的横向对比：

锁	特性	是否支持重入	是否支持锁升级	适合场景
ReentrantLock	独占可重入	是	无	纯写入
ReentrantReadWriteLock	非独占可重读，读写锁，悲观锁	是	否	读写均衡
StampedLock	非独占不可重入，多模式锁，乐观锁	否	是	读多写少

结语

本篇，我们对J.U.C包中的三种类型的锁进行了简要介绍，同时对它们的特性进行了对比，相比于Java同步关键字synchronized来实现线程同步，J.U.C中丰富的锁类型可以更加适应今天复杂的业务场景的需求，根据自己的实际业务需要选择正确合适的锁类型，显得尤为关键，希望本篇可以为您带来一些参考。