转载

面试官：知道Java1.8中新加的StampedLock吗?

Java1.8引入了一个新锁StampedLock，这个锁可以认为是ReadWriteLock的改进。

我们知道在ReadWriteLock中写和读是互斥的，也就是如果有一个线程在写共享变量的话，其他线程读共享变量都会阻塞。

StampedLock把读分为了悲观读和乐观读，悲观读就等价于ReadWriteLock的读，而乐观读在一个线程写共享变量时，不会被阻塞，乐观读是不加锁的。所以没锁肯定是比有锁的性能好，这样的话在大并发读情况下效率就更高了！

StampedLock的用法稍稍有点不同，在获取锁和乐观读时，都会返回一个stamp,解锁时需要传入这个stamp，在乐观读时是用来验证共享变量是否被其他线程写过。来看一下官方示例

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);
     }
   }
 }
复制代码

其上的操作在乐观读时，如果有写操作修改了共享变量则升级乐观读为悲观读锁，这样避免乐观读反复的循环等待写锁的释放，避免浪费CPU资源。所以在我们的使用StampedLock的时候，建议这样操作。

看起来好像StampedLock性能又比ReadWriteLock锁好，那是不是都可以用StampedLock抛弃ReadWriteLock？

并不是的， StampedLock不是可重入锁，所以不支持重入，并且StampedLock不支持条件变量，也就是没Condition。如果是线程使用writeLock()或者readLock()获得锁之后，线程还没执行完就被interrupt()的话，会导致CPU飙升....坑啊我们来看下源码

public long readLock() {
    long s = state, next;  // bypass acquireRead on common uncontended case
    return ((whead == wtail && (s & ABITS) < RFULL &&
            U.compareAndSwapLong(this, STATE, s, next = s + RUNIT)) ?
            next : acquireRead(false, 0L));   //当CAS失败之后就会尝试申请锁，注意第一个参数是false
}

public long writeLock() {
    long s, next;  // bypass acquireWrite in fully unlocked case only
    return ((((s = state) & ABITS) == 0L &&
            U.compareAndSwapLong(this, STATE, s, next = s + WBIT)) ?
            next : acquireWrite(false, 0L)); //当CAS失败之后就会尝试申请锁，注意第一个参数是false
}
//就拿acquireWrite举例，acquireRead也是类似的。
private long acquireWrite(boolean interruptible, long deadline) {
        WNode node = null, p;
        for (int spins = -1;;) { // spin while enqueuing
             //省略代码无数
            if (interruptible && Thread.interrupted())
                return cancelWaiter(node, node, true);
                }
    }

复制代码

首先里面是个无限循环，然后 if (interruptible && Thread.interrupted()) 已经得知调用的interruptible参数传入的是false，所以 Thread.interrupted() 也不会执行到，也一定调用不到 cancelWaiter ，所以就一直循环循环，CPU使用率就会涨涨涨。