多线程-StampLock

by shihang.mai

0. 前言

大神Doug Lea在类上注释已经有使用例子,这里贴一下

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

1. 数据结构

  • StampLock内部会维护一个CLH队列。

每一个节点是一个WNode(Wait Node)

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
}

当队列中有若干个线程等待,就会像下面的图一样

StampLock队列举例.png
  • 锁状态位state
private transient volatile long state;
private static final long ORIGIN = WBIT << 1;
private static final long WBIT  = 1L << LG_READERS;
private static final int LG_READERS = 7;
public StampedLock() {
        state = ORIGIN;
}

上面是long state的初始化的值,即1<<8( ...0001 0000 0000)

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

上面是加写锁,将state += WBIT(1<<7),即 ...0001 1000 0000

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

上面是释放写锁,将state = (stamp += WBIT),即 ...0010 0000 0000
这里相当于把释放锁的次数也记录了,记录它的目的是因为整个state 的状态判断都是基于CAS操作的。而普通的CAS操作可能会遇到ABA的问题,如果不记录次数,那么当写锁释放掉,申请到,再释放掉时,我们将无法判断数据是否被写过


这里继续说一下前7位,它是用来记录读线程的数量的,所以它最大记录126个,超过的部分存放在readerOverflow

private static final long RFULL = RBITS - 1L;
private static final long RBITS = WBIT - 1L;
private static final long WBIT  = 1L << LG_READERS;
private static final int LG_READERS = 7;
private transient int readerOverflow;

总结一下,如图


StampLock状态位.png

2. 写锁的加锁和释放

  • 加锁
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设置state失败,表示写锁申请失败,这时,会调用acquireWrite(),而对于这个方法,比较复杂,就简单总结一下就是


StampLock获取写锁主要步骤.png
  • 释放锁
  1. 恢复state中写锁标志位为0
  2. 同时增加释放锁次数
  3. 唤醒后续线程
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);
    }

3. 读锁的加锁和释放

  • 加锁
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));
    }

队列中没有写锁&&读线程个数没有超过126,直接获得锁,并且读线程数量加1。这里也有一个acquireRead(),简单总结一下


StampLock获取读锁主要流程.png
  • 释放锁
  1. state读线程数-1
  2. 唤醒下一个线程
public void unlockRead(long stamp) {
        long s, m; WNode h;
        for (;;) {
            if (((s = state) & SBITS) != (stamp & SBITS) ||
                (stamp & ABITS) == 0L || (m = s & ABITS) == 0L || m == WBIT)
                throw new IllegalMonitorStateException();
            if (m < RFULL) {
                if (U.compareAndSwapLong(this, STATE, s, s - RUNIT)) {
                    if (m == RUNIT && (h = whead) != null && h.status != 0)
                        release(h);
                    break;
                }
            }
            else if (tryDecReaderOverflow(s) != 0L)
                break;
        }
    }

4. 使用不当会打满CPU

public class StampedLockTest {
    public static void main(String[] args) throws InterruptedException {
        final StampedLock lock = new StampedLock();
        Thread t1 = new Thread(() -> {
            // 获取写锁
            lock.writeLock();
            // 模拟程序阻塞等待其他资源
            LockSupport.park();
        });
        t1.start();
        // 保证t1获取写锁
        Thread.sleep(100);
        Thread t2 = new Thread(() -> {
            // 阻塞在悲观读锁
            lock.readLock();
        });
        t2.start();
        // 保证t2阻塞在读锁
        Thread.sleep(100);
        // 中断线程t2,会导致线程t2所在CPU飙升
        t2.interrupt();
        t2.join();
    }
}
image.png

原因如下:


StampLock获取读锁主要流程.png
  1. 如果没有中断,那么阻塞在readLock()上的线程在经过几次自旋后,会进入park()等待,一旦进入park()等待,就不会占用CPU了。
  2. 但是park()这个函数有一个特点,就是一旦线程被中断,park()就会立即返回,也不抛异常。
  3. 而线程中断标记一直打开着,不停的自选,所以CPU就爆满了。

解决
在StampedLock内部,在park()返回时,需要判断中断标记位,并作出正确的处理,比如,退出,抛异常,或者把中断位给清理一下

你可能感兴趣的:(多线程-StampLock)