三.多线程JUC篇-3.11 StampedLock

Bertha 。 2022-12-20 11:30 179阅读 0赞

## 1.为什么会有StampedLock ##

饥饿问题：ReentrantReadWriteLock实现了读写分离，想要获取读锁就必须确保当前没有其他任何读写锁了，但是一旦读操作比较多的时候，想要获取写锁就变得比较困难了，因为当前有可能会一直存在读锁。而无法获得写锁。

这时候怎么办呢？于是在jdk1.8的时候引入了一个新的锁StampedLock。

## 2.StampedLock介绍 ##

*  StampedLock控制锁有三种模式（写，悲观读，乐观读），一个StampedLock状态是由版本和模式两个部分组成，锁获取方法返回一个数字作为票据stamp，它用相应的锁状态表示并控制访问，数字0表示没有写锁被授权访问。在读锁上分为悲观锁和乐观锁。
 *  所谓的乐观读模式，也就是若读的操作很多，写的操作很少的情况下，你可以乐观地认为，写入与读取同时发生几率很少，因此不悲观地使用完全的读取锁定，程序可以查看读取资料之后，是否遭到写入执行的变更，再采取后续的措施（重新读取变更信息，或者抛出异常） ，这一个小小改进，可大幅度提高程序的吞吐量！！

## 3.StampedLock使用 ##

StampedLock控制锁有三种模式（写，读，乐观读）

*  写入（Writing）：writeLock是一个独占锁，也是一个悲观锁。
 *  读取（Reading）：readLock这时候是一个悲观锁。
 *  乐观读取（Optimistic Reading）：提供了tryOptimisticRead方法返回一个非0的stamp，只有当前同步状态没有被写模式所占有是才能获取到。乐观读取模式仅用于短时间读取操作时经常能够降低竞争和提高吞吐量。同时使用的时候一般需要读取并存储到另外一个副本，以用做对比使用。下面干脆使用代码来实现一下这几种锁的实现。

## 4.例子 ##

class Point { 
       private double x, y;
       private final StampedLock sl = new StampedLock();
       
       //写锁-排他锁
       void move(double deltaX, double deltaY) {  // an exclusively locked method
         long stamp = sl.writeLock();
         try { 
           x += deltaX;
           y += deltaY;
         } finally { 
           sl.unlockWrite(stamp);
         }
       }
       
       //下面看看乐观读锁案例
       double distanceFromOrigin() {  // A read-only method
         long stamp = sl.tryOptimisticRead(); //获得一个乐观读锁
         double currentX = x, currentY = y; //将两个字段读入本地局部变量
         if (!sl.validate(stamp)) {  //检查发出乐观读锁后同时是否有其他写锁发生？
            stamp = sl.readLock(); //如果没有，我们再次获得一个读悲观锁
            try { 
              currentX = x; // 将两个字段读入本地局部变量
              currentY = y; // 将两个字段读入本地局部变量
            } finally { 
               sl.unlockRead(stamp);
            }
         }
         return Math.sqrt(currentX * currentX + currentY * currentY);
       }
       
       //下面是悲观读锁案例
       void moveIfAtOrigin(double newX, double newY) {  // upgrade
         // Could instead start with optimistic, not read mode
         long stamp = sl.readLock();
         try { 
           while (x == 0.0 && y == 0.0) {  //循环，检查当前状态是否符合
             long ws = sl.tryConvertToWriteLock(stamp); //将读锁转为写锁
             if (ws != 0L) {  //这是确认转为写锁是否成功
               stamp = ws; //如果成功 替换票据
               x = newX; //进行状态改变
               y = newY; //进行状态改变
               break;
             }
             else {  //如果不能成功转换为写锁
               sl.unlockRead(stamp); //我们显式释放读锁
               stamp = sl.writeLock(); //显式直接进行写锁 然后再通过循环再试
             }
           }
         } finally { 
           sl.unlock(stamp); //释放读锁或写锁
         }
       }
     }

## 5.总结 ##

*  synchronized：  
    (1) 是在JVM层面上实现的，不但可以通过一些监控工具监控synchronized的锁定，而且在代码执行时出现异常，JVM会自动释放锁定  
    (2) 总结来说，在并发量低与高情况下，synchronized是一个很好的通用的锁实现  
    (3) synchronized不可中断  
    (4) synchronized不能条件等待
 *  ReentrantLock、ReentrantReadWriteLock,、StampedLock都是对象层面的锁定，要保证锁定一定会被释放，就必须将unLock()放到finally\{\}中
 *  StampedLock 对吞吐量有巨大的改进，特别是在读线程越来越多的场景下
 *  StampedLock有一个复杂的API，对于加锁操作，很容易误用其他方法
 *  StampedLock、ReadWriteLock以及synchronized的比较，可以参考国外一个博客，http://ifeve.com/java-8-stampedlocks-vs-readwritelocks-and-synchronized/ 对该博客做了翻译，该文章阐述了不同并发读写线程的数量将决定你应该使用哪一款锁