StampedLock相对于ReentrantReadWriteLock性能提升的原理

StampedLock比ReentrantReadWriteLock性能更好，主要体现在以下几个方面：
1、增加乐观读功能，减少写线程饥饿现象出现
2、StampedLock要比ReentrantReadWriteLock消耗小
3、StampedLock增加了更多的无锁操作，使线程间阻塞减少到最小。
那么它为什么能做到这些呢？
主要实现的逻辑就是：
1、写状态每写一次增加一次值，可以通过比较两次获取到的写状态的值得出是否在获取两次写状态值之间有没有写操作。
2、乐观读的时候，业务层面假设是没有写线程在同时竞争数据资源的，先获取读之前的写状态并记录，等读完后再比较读之前的状态和现在的状态是否相等，如果相等就表示没有写操作执行过，否则就进入到悲观读逻辑（有点儿像偏向锁和轻量级锁的升级）。
3、悲观读的时候，先把读状态变量加1，释放时把读变量减一。
4、写的时候，把写状态变量加1，释放的时候再加1，变量末尾那个bit就可以表示写标识，而整个变量标识写的次数，避免了BAB问题。
我们分析一下源码可以看看它是具体如何实现上面的逻辑的。
先把几个常用的bit操作变量贴出来并配上二进制字符注释：

private static final int LG_READERS = 7;
//0000 0000 0001
private static final long RUNIT = 1L;  
//0000 1000 0000             
private static final long WBIT  = 1L << LG_READERS; 
//0000 0111 1111
private static final long RBITS = WBIT - 1L;  
//0000 0111 1110      
private static final long RFULL = RBITS - 1L;   
//0000 1111 1111    
private static final long ABITS = RBITS | WBIT;  
//1111 1000 0000   
private static final long SBITS = ~RBITS;           
//初始化时state的值
//0001 0000 0000
private static final long ORIGIN = WBIT << 1;       

1、写获取锁和释放锁

public long writeLock() {
        long next;
        return ((next = tryWriteLock()) != 0L) ? next : acquireWrite(false, 0L);
    }

 @ReservedStackAccess
    public long tryWriteLock() {
        long s;
        return (((s = state) & ABITS) == 0L) ? tryWriteLock(s) : 0L;
    }

private long tryWriteLock(long s) {
        // assert (s & ABITS) == 0L;
        long next;
        if (casState(s, next = s | WBIT)) {
            VarHandle.storeStoreFence();
            return next;
        }
        return 0L;
    }

这个方法的调用栈其实也不复杂，我们要搞清楚一个关键就是(s = state) & ABITS这个操作是什么意思。
state其实就类似于ReentrantReadWriteLock的state，前面7个bit是记录读操作线程的个数，第8位是写操作线程的标志位，8位以后都是写操作的总次数。下面举个例子：
state初始化为：0001 0000 0000
有一个读锁：0001 0000 0001
有两个读锁：0001 0000 0010
第一次获取写锁（此时不能有读锁）：0001 0000 0000 + 000010000000 = 000110000000
第一次释放写锁：000110000000 + 000010000000 = 001000000000
第二次获取写锁：0010 0000 0000 + 0000 1000 0000 = 0010 1000 0000
第二次释放写锁：
0010 1000 0000 + 0000 1000 0000 = 0011 0000 0000

ABITS的二进制字符形式：0000 1111 1111
如果state和ABITS与操作如果为零就是没有读锁也没有写锁。如果不为0，就表示有读锁或者写锁。
后面的tryWriteLock(s)方法就是用cas把加锁的state变量值替换原来的变量值。

 @ReservedStackAccess
    public void unlockWrite(long stamp) {
        if (state != stamp || (stamp & WBIT) == 0L)
            throw new IllegalMonitorStateException();
        unlockWriteInternal(stamp);
    }

  private long unlockWriteInternal(long s) {
        long next; WNode h;
        STATE.setVolatile(this, next = unlockWriteState(s));
        if ((h = whead) != null && h.status != 0)
            release(h);
        return next;
    }

 private static long unlockWriteState(long s) {
        return ((s += WBIT) == 0L) ? ORIGIN : s;
    }

释放锁的逻辑就是用CAS把加了0000 1000 0000的sate变量替换掉原来的变量，如果排队队列中的线程节点不为空，就唤醒一个线程节点去竞争锁。

2、悲观读锁的获取与释放

 @ReservedStackAccess
    public long readLock() {
        long s, next;
        // bypass acquireRead on common uncontended case
        return (whead == wtail
                && ((s = state) & ABITS) < RFULL
                && casState(s, next = s + RUNIT))
            ? next
            : acquireRead(false, 0L);
    }

  @ReservedStackAccess
    public void unlockRead(long stamp) {
        long s, m; WNode h;
        while (((s = state) & SBITS) == (stamp & SBITS)
               && (stamp & RBITS) > 0L
               && ((m = s & RBITS) > 0L)) {
            if (m < RFULL) {
                if (casState(s, s - RUNIT)) {
                    if (m == RUNIT && (h = whead) != null && h.status != 0)
                        release(h);
                    return;
                }
            }
            else if (tryDecReaderOverflow(s) != 0L)
                return;
        }
        throw new IllegalMonitorStateException();
    }

这里读锁也是通过CAS修改sate低7位加1，，不同于ReentrantReadWriteLock，StampedLock的读锁很容易溢出，最大只有127，超过后通过一个额外的变量readerOverflow来存储。
如果CAS获取读锁失败，也会把线程构造成节点加入阻塞队列，这里就是ReentrantReadWriteLock是一样的，构造成节点后，如果读线程没有溢出，就死循环CAS一段时间，如果还是获取不到锁，就把节点加入阻塞队列。
读锁的释放也是和写锁的释放是类似的，通过减少sate变量低7位的数据，CAS替换，如果阻塞队列不为空，就唤醒一个线程竞争锁。

3、乐观锁的获取与验证

   public long tryOptimisticRead() {
        long s;
        return (((s = state) & WBIT) == 0L) ? (s & SBITS) : 0L;
    }

public boolean validate(long stamp) {
        VarHandle.acquireFence();
        return (stamp & SBITS) == (state & SBITS);
    }

其中乐观锁的使用类似于：

long stamp = stampedLock.tryOptimisticRead();

//do something

if(!stampedLock.validate(stamp)){
stamp = stampedLock.readLock();
try{
// do something
}finally{
stampedLock.unlockRead(stamp);
}
}
先获取乐观锁，然后做业务逻辑，完成业务逻辑后再验证数据是否被写过，如果被写过就获取悲观锁，从新做业务逻辑，最后释放悲观锁。

乐观锁的获取只有是尝试修改了sate变量，修改不成功就返回失败，不会阻塞线程构造成节点加入阻塞队列。