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行）。