(十)J.U.C之locks框架：StampedLock

一、简介

StampedLock类，在JDK1.8时引入，是对读写锁ReentrantReadWriteLock的增强，该类提供了一些功能，优化了读锁、写锁的访问，同时时读写锁之间可以互相转换，更细粒度控制并发。

首先明确下，该类的设计初衷是作为一个内部工具类，用于辅助开发其他线程安全组件，用得好，该类可以提升系统性能，用不好，容易产生死锁和其它莫名其妙的问题。

 

1.1StampedLock的引入

为什么有了ReentrantReadWriteLock，还要引入StampedLock？

ReentrantReadWriteLock使得多个读线程同时持有读锁(只要写锁未被占用)，而写锁是独占的。

但是，读写锁如果使用不当，很容易产生“饥饿”问题：

比如在读线程非常多，写线程很少的情况下，很容易导致写线程“饥饿”，虽然使用“公平”策略可以一定程度上缓解这个问题，但是“公平”策略是以牺牲系统吞吐量为代价的。

 

1.2StampedLock的特点

1.所有获取锁的方法，都返回一个邮戳(Stamp)，Stamp为0表示获取失败，其余都表示成功；

2.所有释放锁的方法，都需要一个邮戳(Stamp)，这个Stamp必须是和成功获取锁时得到的Stamp一致；

3.StampedLock是不可重入的；（如果一个线程已经持有了写锁，再去获取写锁的话就会造成死锁）

4.StampedLock有三种访问模式：

   ①Reading(读模式)：功能和ReentrantReadWriteLock的读锁类似；

   ②Writing(写模式)：功能和ReentrantReadWriteLock的写锁类似；

   ③Optimistic reading(乐观读模式)：这是一种优化的读模式；

5.Stamped支持读锁和写锁的相互转换

   我们知道ReentrantReadWriteLock中，当线程获取到写锁后，可以降级为读锁，但是读锁是不能直接升级为写锁的。         StampedLock提供了读锁和写锁相互转换的功能，使得该类支持更多的应用场景；

6.无论写锁还是读锁，都不支持Condition等待；

 

我们知道，在ReentrantReadWriteLock中，当读锁被使用时，如果有线程尝试获取写锁，该写线程会阻塞。
但是，在Optimistic reading中，即使读线程获取到了读锁，写线程尝试获取写锁也不会阻塞，这相当于对读模式的优化，但是可能会导致数据不一致的问题。所以，当使用Optimistic reading获取到读锁时，必须对获取结果进行校验。

 

 

具体原理和使用示例请查看https://segmentfault.com/a/1190000015808032