【Java并发工具类】StampedLock：比读写锁更快的锁
前言
ReadWriteLock适用于读多写少的场景，允许多个线程同时读取共享变量。但在读多写少的场景中，还有更快的技术方案。在Java 1.8中， 提供了StampedLock锁，它的性能就比读写锁还要好。下面我们介绍StampedLock的使用方法、内部工作原理以及在使用过程中需要注意的事项。
StampedLock支持的三种锁模式
ReadWriteLock支持两种访问模式：读锁和写锁，而StampedLock支持三种访问模式：写锁、悲观读锁和乐观读。
其中写锁和悲观读锁的语义与ReadWriteLock中的写锁和读锁语义类似，允许多个线程同时获取悲观读锁，只允许一个线程获取写锁。与ReadWriteLock不同的是，StampedLock中的写锁和悲观读锁加锁成功之后，都会返回一个stamp标记，然后解锁的时候需要传入这个stamp。
相关示例代码如下（代码来自参考[1]）
final StampedLock sl = new StampedLock();// 获取/释放悲观读锁示意代码long stamp = sl.readLock();try {//省略业务相关代码} finally {sl.unlockRead(stamp);}// 获取/释放写锁示意代码long stamp = sl.writeLock();try {//省略业务相关代码} finally {sl.unlockWrite(stamp);}
StampedLock的性能之所以比ReadWriteLock好，其关键在于StampedLock支持乐观读。ReadWriteLock支持多个线程同时读，当多个线程同时读的时候，所有的写操作都会被阻塞。但是，StampedLock提供了乐观读，当有多个线程同时读共享变量允许一个线程获取写锁，也就是说不是所有写操作都会被阻塞。
需要注意，StampedLock提供的是“乐观读”而不是“乐观读锁”，这表示乐观读是无锁的，这也是其比ReadWriteLock读锁性能好的原因。
乐观读的使用示例（代码来自参考[1]）：
class Point{private int x, y;final StampedLock sl = new StampedLock();// 计算到原点的距离double distanceFromOrigin() {long stamp = sl.tryOptimisticRead(); //乐观读//读取全局变量存储到局部变量中 在读入的过程中，数据可能被修改int curX = x;int curY = y;//判断进行读操作期间，是否存在写操作，如果存在，则sl.validate(stamp)返回falseif(!sl.validate(stamp)) {stamp = sl.readLock(); //升级为悲观读锁 一切的写操作都会被阻塞try {curX = x;curY = y;}finally {sl.unlockRead(stamp); //释放悲观读锁}}return Math.sqrt(curX*curX + curY*curY);}}
我们将共享变量x，y读入方法的局部变量中，因为tryOptimisticRead()是无锁的，所以，共享变量x和y读入方法局部变量时，x和y有可能被其他线程修改了。因此，最后读完之后，还需要再次验证一下在读入过程中是否存在写操作，这个验证操作是通过调用validate(stamp)来实现的。
如果在执行乐观读操作期间，存在写操作，会把乐观读升级为悲观读锁。
如果不使用这种做法，那么就可能需要使用循环来执行反复读，直到执行乐观读操作的期间没有写操作，但是循环会浪费大量的CPU。
所以，升级为悲观读锁，代码简练且不易出错。
StampedLock乐观读的理解
数据库中的乐观锁与StampedLock中的乐观读有着异曲同工之妙。
通过下面这个例子来理解：
在ERP的生产模块中，会有多个人通过ERP系统提供的UI同时修改同一条生产订单，那如何保证生产订单数据是并发安全的？
一种解决方案是采用乐观锁。
在生产订单的表product_doc里面增加了一个数据型版本号字段vresion,每次更新product_doc这个表的时候,都将version字段加1。生产订单的UI在展示的时候，需要查询数据库，此时将这个version字段和其他业务字段一起返回给生产订单UI。
假设用户查询的生产订单的id=777，那么SQL语句类似如下：
select id, ..., versionfrom product_docwhere id=777
用户在生产订单UI执行保存操作的时候，后台利用下面的SQL语句更新生产订单，此处我们假设该条生产订单的version=4：
update product_docset version=version+1，...where id=777 and version=4
如果这条SQL语句执行成功并且返回条数等于1，那么说明从生产订单UI执行查询操作到执行保存期间，没有其他人修改过这条数据。因为如果这期间有人修改过这条数据，那么版本号字段一定会大于4。
数据库中的乐观锁，查询的时候，需要把version字段查出来，更新的时候要利用version字段做验证。StampedLock里面的stamp就类似于这个version字段。
StampedLock使用注意事项
StampedLock的功能仅仅是ReadWriteLock的子集，所以在使用时，还是需要注意一些地方：
-
StampedLock在命名上没有增加
Reentrant，所以，猜想StampedLock不支持重入。事实上，确实如此，StampedLock是不支持重入的。 -
StampedLock的悲观读锁、写锁都不支持条件变量。
-
如果线程阻塞在 StampedLock 的
readLock()或者writeLock()上时，调用该阻塞线程的interrupt()方法，会导致 CPU 飙升。（代码来自参考[1]）final StampedLock lock = new StampedLock();Thread T1 = new Thread(()->{lock.writeLock(); // 获取写锁LockSupport.park(); // 永远阻塞在此处，不释放写锁});T1.start();Thread.sleep(100); // 保证T1获取写锁Thread T2 = new Thread(()->lock.readLock() ); //阻塞在悲观读锁T2.start();Thread.sleep(100); // 保证T2阻塞在读锁//中断线程T2 会导致线程T2所在CPU飙升T2.interrupt();T2.join();
线程 T1 获取写锁之后将自己阻塞，线程 T2 尝试获取悲观读锁，也会阻塞；如果此时调用线程 T2 的 interrupt() 方法来中断线程 T2 的话，会发现线程 T2 所在 CPU 会飙升到 100%。（看专栏时明白线程T2获取悲观读锁会被阻塞，但是直到现在也不明白为什么调用T2的interrupt()方法会导致CPU飙升，望路过的看官解答。)
替代方法便是使用悲观读锁readLockInterruptibly()和写锁writeLockInterruptibly()。
StampedLock官方示例使用读写锁模板
精简Java官方示例后，可形成如下模板（代码来自参考[1]）
StampedLock读模板：
final StampedLock sl = new StampedLock();long stamp = sl.tryOptimisticRead(); // 乐观读// 读入方法局部变量//......// 校验stampif (!sl.validate(stamp)){stamp = sl.readLock(); // 升级为悲观读锁try {// 读入方法局部变量.....} finally {sl.unlockRead(stamp); //释放悲观读锁}}//使用方法局部变量执行业务操作//......
StampedLock写模板：
long stamp = sl.writeLock();try {// 写共享变量......} finally {sl.unlockWrite(stamp);}
小结
这篇博客是学习专栏时的笔记总结出来的结果，粗略地介绍了一下StampedLock，欲知更详细的请参考[3]，无意中发现的大神博客，推荐起(•̀ᴗ•́)و ̑̑
参考：
[1] 极客时间专栏王宝令《Java并发编程实战》
[2] whoshiyeguiren.数据库乐观锁和悲观锁的理解和实现（转载&总结）.https://blog.csdn.net/woshiyeguiren/article/details/80277475
[3] Ressmix.Java多线程进阶（十一）—— J.U.C之locks框架：StampedLock.https://segmentfault.com/a/1190000015808032?utm_source=tag-newest