StampedLock知识点梳理

接下来几篇文章会对JUC并发包里面的锁工具类做下梳理，如：ReentrantLock、

ReentrantReadWriteLock、StampedLock

三种模式：

• 写锁
• 悲观读锁
• 乐观读

其中，写锁、悲观读锁的语义和 ReadWriteLock 的写锁、读锁的语义非常类似，允许多个线程同时获取悲观读锁，但是只允许一个线程获取写锁，写锁和悲观读锁是互斥的。

不同的是：StampedLock 里的写锁和悲观读锁加锁成功之后，都会返回一个 stamp；然后解锁的时候，需要传入这个 stamp。

主要方法：

• long writeLock() ，阻塞式获取写锁
• long tryWriteLock()，非阻塞式获取写锁，如果是0，表示没有拿到写锁
• long tryWriteLock(long time, TimeUnit unit)，同上，支持超时时间
• long writeLockInterruptibly()，阻塞式获取写锁，支持中断
• long readLock()，阻塞式获取悲观读锁
• long tryReadLock()，非阻塞式获取悲观读锁，如果是0，表示没有拿到锁
• long tryReadLock(long time, TimeUnit unit)，同上
• long readLockInterruptibly()，阻塞式获取悲观读锁，支持中断
• long tryOptimisticRead()，获取乐观读的版本号
• boolean validate(long stamp)，验证上面的版本号是否通过，期间是否有修改
• void unlockWrite(long stamp) ，释放写锁
• void unlockRead(long stamp)，释放悲观读锁
• void unlock(long stamp)，释放锁，笼统
• long tryConvertToWriteLock(long stamp)，升级读锁为写锁，非阻塞式，不满足返回0
• 其它的一些方法，主要用于监控，数据采集

特性：

• 不支持重入
• 写锁、悲观读锁都不支持条件变量
• 一定不要调用中断操作，如果需要支持中断功能，一定使用可中断的悲观读锁 readLockInterruptibly() 和写锁 writeLockInterruptibly()

与ReadWriteLock比较：

• ReadWriteLock 支持多个线程同时读，但是当多个线程同时读的时候，所有的写操作会被阻塞，可能导致写的饥饿问题（读操作一直都能抢占到CPU时间片，而写操作一直抢不了）
• StampedLock 的性能比 ReadWriteLock 好。主要是 StampedLock 支持乐观读的方式。当在乐观读期间，允许另一个线程获取写锁。那么怎样保证读和写的一致性呢？通过validate（）方法，如果校验不通过，说明期间有修改，可以再重试一次。

乐观读，使用模板：

final StampedLock sl =  new StampedLock();
 
// 乐观读
long stamp = sl.tryOptimisticRead();

// 读入方法局部变量
......
// 校验 stamp
if (!sl.validate(stamp)){
  // 升级为悲观读锁
  stamp = sl.readLock();
  try {
    // 读入方法局部变量
    .....
  } finally {
    // 释放悲观读锁
    sl.unlockRead(stamp);
  }
}
// 使用方法局部变量执行业务操作
......