StampedLock原理

原文链接:https://blog.csdn.net/sunhaoning/article/details/68924625

StamppedLock是Java 8中引入的一种新的锁机制。读写锁虽然分离了读和写的功能，使得读与读之间可以完全并发。但是，读和写之间依然是冲突的。读锁会完全阻塞写锁，它使用的依然是悲观锁的策略，如果有大量的读线程，它也有可能引起写线程的“饥饿”。

而StampedLock提供了一种乐观的读策略。这种乐观策略的锁非常类似无锁的操作，使得乐观锁完全不会阻塞写线程。

1）StampedLock使用示例

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);

}

 

上述代码出自JDK的官方文档。它定义了一个Point类，内部有两个元素x和y，表示点的坐标。第3行定义了StampedLock锁。第15行定义的distanceFromOrigin()方法是一个只读方法，它只会读取Point的x和y坐标。在读取时，首先使用了StampedLock.tryOptimisticRead()方法。这个方法表示试图尝试一次乐观读。它会返回一个类似于时间的邮戳整数stamp。这个stamp就可以作为这一次锁获取的凭证。

接着，在第17行，读取x和y的值。当然，这时并不确定这个x和y是否是一致的（在读取x的时候，可能其他线程改写了y的值，使得currentX和currentY处于不一致的状态）。因此，我们必须在18行，使用validate()方法，判断这个stamp是否在读过程发生期间被修改过。如果stamp没有被修改过，则认为这次读取的过程中，可能被其他线程改写了数据，因此，有可能出现了脏读。如果出现这种情况，我们可以像处理CAS操作那样在一个死循环中一直使用乐观读，知道成功为止。

也可以升级锁的级别。在本例中，我们升级乐观锁的级别，将乐观锁变为悲观锁。在第19行，当判断乐观读失败后，使用readLock()获得悲观的读锁，并进一步读取数据。如果当前对象正在被修改，则读锁的申请可能导致线程挂起。

写入的情况可以参考第5行定义的move()函数。使用writeLock()函数可以申请写锁。这里的含义和读写锁是类似的。

在退出临界区时，不要忘记释放写锁（第11行）或者读锁（第24行）。

2）StampedLock的小陷阱

StampedLock内部实现时，使用类似于CAS操作的死循环反复尝试的策略。在它挂起线程时，使用的是Unsafe.park()函数，而park()函数在遇到线程中断时，会直接返回（不同于Thread.sleep()，它不会抛出异常）。而在StampedLock的死循环逻辑中，没有处理有关中断的逻辑。因此，这就会导致阻塞在park()上的线程被中断后，会再次进入循环。而当退出条件得不到满足时，就会发生疯狂占用CPU的情况。下面演示了这个问题：

public class StampedLockCUPDemo {

static Thread[] holdCpuThreads = new Thread[3];

static final StampedLock lock = new StampedLock();

public static void main(String[] args) throws InterruptedException {

new Thread() {

public void run(){

long readLong = lock.writeLock();

LockSupport.parkNanos(6100000000L);

lock.unlockWrite(readLong);

}

}.start();

Thread.sleep(100);

for( int i = 0; i < 3; ++i) {

holdCpuThreads [i] = new Thread(new HoldCPUReadThread());

holdCpuThreads [i].start();

}

Thread.sleep(10000);

for(int i=0; i<3; i++) {

holdCpuThreads [i].interrupt();

}

}

private static class HoldCPUReadThread implements Runnable {

public void run() {

long lockr = lock.readLock();

System.out.println(Thread.currentThread().getName() + " get read lock");

lock.unlockRead(lockr);

}

}

}

 

在上述代码中，首先开启线程占用写锁（第7行），为了演示效果，这里使用写线程不释放锁而一直等待。接着，开启3个读线程，让它们请求读锁。此时，由于写锁的存在，所有读线程都会被最终挂起。

读线程因为park()的操作进入了等待状态，这种情况是正常的。

而在10秒钟以后（代码在17行执行了10秒等待），系统中断了这3个读线程，之后，就会发现，CPU占用率极有可能会飙升。这是因为中断导致park()函数返回，使线程再次进入运行状态。

此时，这个线程的状态是RUNNABLE，这是我们不愿意看到的，它会一直存在并耗尽CPU资源，直到自己抢占到了锁。

 

3）有关StampedLock的实现思想

StampedLock的内部实现是基于CLH锁的。CLH锁是一种自旋锁，它保证没有饥饿发生，并且可以保证FIFO的服务顺序。

CLH锁的基本思想如下：锁维护一个等待线程队列，所有申请锁，但是没有成功的线程都记录在这个队列中。每一个节点（一个节点代表一个线程），保存一个标记位（locked），用于判断当前线程是否已经释放锁。

当一个线程试图获得锁时，取得当前等待队列的尾部节点作为其前序节点，并使用类似如下代码判断前序节点是否已经成功释放：

while(pred.locked) {

}

只要前序节点（pred）没有释放锁，则表示当前线程还不能继续执行，因此会自旋等待(很多synchronized里面的代码只是一些很简单的代码，执行时间非常快，此时等待的线程都加锁可能是一种不太值得的操作，因为线程阻塞涉及到用户态和内核态切换的问题。既然synchronized里面的代码执行得非常快，不妨让等待锁的线程不要被阻塞，而是在synchronized的边界做忙循环，这就是自旋。如果做了多次忙循环发现还没有获得锁，再阻塞，这样可能是一种更好的策略。)。

反之，如果前序线程已经释放锁，则当前线程可以继续执行。

释放锁时，也遵循这个逻辑，线程会将自身节点的locked位置标记为false，那么后续等待的线程就能继续执行了。

在StampedLock内部，为维护一个等待链表队列：

static final class WNode {

volatile WNode prev;

volatile WNode next;

volatile WNode cowait; // list of linked readers

volatile Thread thread; // non-null while possibly parked

volatile int status; // 0, WAITING, or CANCELLED

final int mode; // RMODE or WMODE

WNode(int m, WNode p) { mode = m; prev = p; }

}

/** Head of CLH queue */

private transient volatile WNode whead;

/** Tail (last) of CLH queue */

private transient volatile WNode wtail;

上述代码中，WNode为链表的基本元素，每一个WNode表示一个等待线程。字段whead和wtail分别指向等待链表的头部和尾部。

另外一个重要的字段为state：

private transient volatile long state;

字段state表示当前锁的状态。它是一个long型，有64位，其中，倒数第8位表示写锁状态，如果该位为1，表示当前由写锁占用。

对于一次乐观读的操作，它会执行如下操作：

public long tryOptimisticRead() {

long s;

return (((s = state) & WBIT) == 0L) ? (s & SBITS) : 0L;

}

一次成功的乐观读必须保证当前锁没有写锁占用。其中WBIT用来获取写锁状态位，值为0x80。如果成功，则返回当前state的值（末尾7位清零，末尾7位表示当前正在读取的线程数量）。

如果在乐观读后，有线程申请了写锁，那么state的状态就会改变：

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));

}

上述代码中第4行，设置写锁位为1（通过加上WBIT（0x80））。这样，就会改变state的取值。那么在乐观锁确认（validate）时，就会发现这个改动，而导致乐观锁失败。

public boolean validate(long stamp) {

// See above about current use of getLongVolatile here

return (stamp & SBITS) == (U.getLongVolatile(this, STATE) & SBITS);

}

 

上述validate()函数比较当前stamp和发生乐观锁时取得的stamp，如果不一致，则宣告乐观锁失败。

乐观锁失败后，则可以提升锁级别，使用悲观读锁。

public long readLock() {

long s, next; // bypass acquireRead on fully unlocked case only

return ((((s = state) & ABITS) == 0L &&

U.compareAndSwapLong(this, STATE, s, next = s + RUNIT)) ?

next : acquireRead(false, 0L));

}

悲观读会尝试设置state状态（第4行），它会将state加1（前提是读线程数量没有溢出，对于读线程数量溢出的情况，会使用辅助的readerOverflow进行统计），用于统计读线程的数量。如果失败，则进入acquireRead()二次尝试锁获取。

在acquireRead()中，线程会在不同条件下进行若干次自旋，试图通过CAS操作获得锁。如果自旋宣告失败，则会启用CLH队列，将自己加到队列中。之后再进行自旋，如果发现自己成功获得了读锁，则会进一步把自己cowait队列中的读线程全部激活（使用Usafe.unpark()方法）。如果最终依然无法成功获得读锁，则会使用Unsafe.park()方法挂起当前线程。

方法acquireWrite()和acquireRead()也非常类似，也是通过自旋尝试、加入等待队列、直至最终Unsafe.park()挂起线程的逻辑进行的。释放锁时与加锁动作相反，以unlockWrite()为例：

public void unlockWrite(long stamp) {

WNode h;

if (state != stamp || (stamp & WBIT) == 0L)

throw new IllegalMonitorStateException();

state = (stamp += WBIT) == 0L ? ORIGIN : stamp;

if ((h = whead) != null && h.status != 0)

release(h);

}

上述代码第5行，将写标记位清零，如果state发生溢出，则退回到初始值。

接着，如果等待队列不为空，则从等待队列中激活一个线程（绝大部分情况下是第1个等待线程）继续执行（第7行）。