StampedLock的理解和使用

StampedLock介绍

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

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

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

不支持重入

StampedLock如何使用和使用价值

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

1、对于悲观读和悲观写的方法与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);
}

输出结果：

数据写入完成
5064
readLock==0

写被读锁阻塞了5秒

2、对于乐观读（如果没有进入写模式）可以减少一次读锁的性能消耗，并且不会阻塞写入的操作（乐观读遇到写后转化为悲观，相当于滞后一步）

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

private static void optimisticRead() {
    service.submit(() -> {
        long stamp = lock.tryOptimisticRead(); //尝试获取乐观读锁
        int currentCount = count; //获取变量值
        try {
            TimeUnit.MILLISECONDS.sleep(milli);//模拟读取需要花费20秒
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        if (!lock.validate(stamp)) { //判断count是否进入写模式
            stamp = lock.readLock(); //已经进入写模式，没办法只能老老实实的获取读锁
            try {
                currentCount = count; //成功获取到读锁，并重新获取最新的变量值
            } finally {
                lock.unlockRead(stamp); //释放读锁
            }
        }
        //走到这里，说明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);
}

输出结果：

数据写入完成
553

(中间等了大概5秒)
optimisticRead==1

写没有被被读锁阻塞，乐观读最终走了悲观读读取了最新值

证明乐观读锁比悲观读锁性能更好

public class StampedLockXingnengTest {
    static ExecutorService service = Executors.newCachedThreadPool();
    static StampedLock lock = new StampedLock();
    static int count = 0;
    public static void main(String[] args) throws InterruptedException {
        long begin  = System.currentTimeMillis();
        List<Callable<Object>> list = new ArrayList<>();
        for(int i = 0;i < 10000;i++){
            list.add(() -> {
                readLock();
                //optimisticRead();
                return null;
            });
        }
        service.invokeAll(list);
        long end  = System.currentTimeMillis();
        System.out.println(end-begin);
        //乐观95 91 102 98 92
        //悲观265 253 293 265 287
    }


    private static void readLock() {//普通的读锁
        int currentCount = 0;
        long stamp = lock.readLock(); //获取排他读锁
        try {
            Thread.sleep(10);
        } catch (InterruptedException e) {
            e.printStackTrace();
        } finally {
            lock.unlockRead(stamp); //释放读锁
        }
    }


    private static void optimisticRead() {
        long stamp = lock.tryOptimisticRead(); //尝试获取乐观读锁
        int currentCount = count; //获取变量值
        if (!lock.validate(stamp)) { //判断count是否进入写模式
            stamp = lock.readLock(); //已经进入写模式，没办法只能老老实实的获取读锁
            try {
                Thread.sleep(10);
            } catch (InterruptedException e) {
                e.printStackTrace();
            } finally {
                lock.unlockRead(stamp); //释放读锁
            }
        }
    }
}

针对以上代码我分别对乐观读锁和悲观读锁测试了5次，每次10000并发并且每次回sleep10ms，测试结果如下

乐观（ms）95 91 102 98 92
悲观（ms）265 253 293 265 287

乐观读锁整体性能大概是悲观读锁3倍

总结

可以看到相比直接用悲观读锁，乐观读锁可以：

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

2、如果其他线程已经获取了悲观写锁，那么就只能老老实实的获取悲观读锁（这种情况相当于退化成了读写锁）

3、如果其他线程没有获取悲观写锁，那么就不用获取悲观读锁了，减少了一次获取悲观读锁的消耗和避免了因为读锁导致写锁阻塞的问题，直接返回读的数据即可（必须再tryOptimisticRead和validate之间获取好数据，否则数据可能会不一致了，试想如果过了validate再获取数据，这时数据可能被修改并且读操作也没有任何保护措施）