StampedLock的理解和使用

StampedLock介绍

StampedLock是为了优化可重入读写锁性能的一个锁实现工具，jdk8开始引入

相比于普通的ReentranReadWriteLock主要多了一种乐观读的功能

在API上增长了stamp的入参和返回值

不支持重入

StampedLock如何使用和使用价值

我看了上面的介绍仍然对StampedLock一头雾水，下面咱们来揭开StampedLock神秘的面纱

一、对于悲观读和悲观写的方法与ReentranReadWriteLock读写锁效果同样

下面是StampedLock的悲观读、写锁的实现

static ExecutorService service = Executors.newFixedThreadPool(10);
static StampedLock lock = new StampedLock();
static long milli = 5000;
static int count = 0;

private static long writeLock() {
　　long stamp = lock.writeLock(); //获取排他写锁
　　count+=1;
　　lock.unlockWrite(stamp); //释放写锁
　　System.out.println("数据写入完成");
　　return System.currentTimeMillis();
}

    private static void readLock() {//悲观读锁
        service.submit(() -> {
            int currentCount = 0;
            long stamp = lock.readLock(); //获取悲观读锁
            try {
                currentCount = count; //获取变量值
                try {
                    TimeUnit.MILLISECONDS.sleep(milli);//模拟读取须要花费20秒
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            } finally {
                lock.unlockRead(stamp); //释放读锁
            }
            System.out.println("readLock==" + currentCount); //显示最新的变量值
        });
        try {
            TimeUnit.MILLISECONDS.sleep(500);//要等一等读锁先得到
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

测试一下效果：

public static void main(String[] args) {
　　long l1 = System.currentTimeMillis();
　　readLock();　　long l2 = writeLock();
　　System.out.println(l2-l1);
}

由于我对悲观读操做进行了5秒的数据读取延迟，因此写操做要等5秒后读锁释放才能写入数据

输出结果：

数据写入完成的时间比获取读锁晚5043ms

读到的数据仍然是写入前的0

二、对于乐观读（若是没有进入写模式）能够减小一次读锁的性能消耗，而且不会阻塞写入的操做

咱们添加了一个乐观读的方法，这个方法仍然模拟读取延迟5秒，乐观读实现须要参考下面的编程模式（获取乐观锁、校验是否进入写模式）

    private static void optimisticRead() {
        service.submit(() -> {
            long stamp = lock.tryOptimisticRead(); //尝试获取乐观读锁
            int currentCount = count; //获取变量值
            if (!lock.validate(stamp)) { //判断count是否进入写模式
                stamp = lock.readLock(); //已经进入写模式，没办法只能老老实实的获取读锁
                try {
                    currentCount = count; //成功获取到读锁，并从新获取最新的变量值
                } finally {
                    lock.unlockRead(stamp); //释放读锁
                }
            }
            try {
                TimeUnit.MILLISECONDS.sleep(milli);//模拟读取须要花费20秒
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            //走到这里，说明count尚未被写，那么能够不用加读锁，减小了读锁的开销
            System.out.println("optimisticRead==" + currentCount); //显示最新的变量值
        });
        try {
            TimeUnit.MILLISECONDS.sleep(500);//要等一等读锁先得到
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

测试一下效果：

public static void main(String[] args) {
　　long l1 = System.currentTimeMillis();
　　optimisticRead();
　　long l2 = writeLock();
　　System.out.println(l2-l1);
}

直接看一下输出结果：

数据写入完成的时间比获取读锁晚543ms（说明乐观读并无阻塞写操做）

5秒后读到的数据仍然是写入前的0

总结

能够看到相比直接用悲观读锁，乐观读锁能够：

一、进入悲观读锁前先看下有没有进入写模式（说白了就是有没有已经获取了悲观写锁）

二、若是其余线程已经获取了悲观写锁，那么就只能老老实实的获取悲观读锁（这种状况至关于退化成了读写锁）

三、若是其余线程没有获取悲观写锁，那么就不用获取悲观读锁了，减小了一次获取悲观读锁的消耗和避免了由于读锁致使写锁阻塞的问题，直接返回读的数据便可（必须再tryOptimisticRead和validate之间获取好数据，不然数据可能会不一致了，试想若是过了validate再获取数据，这时数据可能被修改而且读操做也没有任何保护措施）