StampedLock解析

Posted on | In
Words count in article: 1.4k | Reading time ≈ 5

StampedLock解析

在Java中，有一个可重入的读写锁ReentrantReadWriteLock，它是一种读写分离的锁，在读或者写的时候，会把写或者读操作先阻塞。但是在读操作和读操作之前却不加锁。即，读操作和写操作是互斥的，但是读操作和读操作之间不是。

这样会存在一个问题，在读操作远大于写操作的情况下，有可能写操作一直被阻塞住，永远无法进行。因此，Java 8 新增了StampedLock类，来解决这个可能存在的问题。

StampedLock在读的时候并不会阻塞写操作，它会在读的时候设置一个标志位，读结束时，校验下该标志位，如果发现已经被改变了，那么就再读一次。

StampedLock提供了三种模式的锁：

  • writeLock：是一个排他锁，某时只有一个线程可以获取该锁，当一个线程获取该锁后，其他请求读锁和写锁的线程必须等待，这类似于ReentrantReadWriteLock的写锁，不同的是，此处的写锁是不可重入的；当前没有线程持有读锁或者写锁时才可以获取到该锁。请求该锁成功后会返回一个stamp变量用来表示该锁的版本，当释放该锁时需要调用unLockWrite方法并传递获取锁时的stamp参数。并且它提供了非阻塞的tryWriteLock方法
  • readLock（悲观锁）：是一个共享锁，在没有线程获取独占写锁的情况下， 多个线程可以同时获取该锁，如果已经有线程持有写锁，则其他线程请求获取该读锁会被阻塞，这类似于ReentrantReadWriteLock的读锁，不同的是此处的读锁是不可重入的。请求该锁成功后会返回一个stamp变量用来表示该锁的版本，当释放该锁时需要调用unLockRead方法并传递stamp参数。并且它提供了非阻塞的tryReadLock方法。
  • tryOptimisticRead（乐观锁）：在操作数据前并没有通过CAS设置锁的状态，仅仅通过位运算测试。如果当前没有线程持有写锁，则简单地返回一个非0的stamp版本信息。获取该stamp后再具体操作数据前还需要调用validate方法验证该stamp是否已经不可用，也就是确认从获取到该锁，到操作数据之前的这段时间，有没有写操作对数据进行了改动。如果是，则validate会返回0，否则，可以使用该stamp版本的锁对数据进行操作。由于tryOptimisticRead并没有使用CAS设置锁状态，所以不需要显式释放锁。该锁的一个特点是适用于读多写少的场景，因为获取读锁只是使用位操作进行检验，不涉及CAS操作，所以效率会高很多，但同时由于没有使用真正的锁，在保证数据一致性上需要复制一份要操作的变量到方法栈，并且在操作数据时可能其他线程已经修改了数据，而我们操作的是方法栈里面的数据，所以最多返回的不是最新的数据。

StampedLock还支持这三种锁在一定条件下进行相互转换。例如 tryConvertToWriteLock方法，会把stamp标记的锁升级为写锁，这个方法会在下面几种情况下返回一个有效的stamp：

  • 当前锁已经是写锁
  • 当前锁是读锁，并且没有其他线程时持有读锁
  • 当前锁时乐观锁，并且当前写锁可用

先看一个官方的案例，体会下StampedLock的用法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
public class Point {
    //内部定义表示坐标点
    private double x, y;
    private final StampedLock s1 = new StampedLock();

    void move(double deltaX, double deltaY) {
  		 // 获取写锁，并拿到此时的stamp
        long stamp = s1.writeLock();
        try {
            x += deltaX;
            y += deltaY;
        } finally {
			// 释放写锁时，传入了获取写锁的stamp，
			// 这也就是下面读方法里面validate能判断stamp是否被修改的原因
            s1.unlockWrite(stamp);
        }
    }
    
 	//只读方法
    double distanceFormOrigin() {
    	 // 试图尝试一次乐观读 返回一个类似于时间戳的整数stamp，它在后面的validate方法中将被验证。
  		 // 如果资源已经被锁住了，则返回0
        long stamp = s1.tryOptimisticRead(); 
        
        //读取x和y的值。这时候我们并不确定x和y是否是一致的
        double currentX = x, currentY = y;
        
        // 判断这个stamp在读的过程中是否被修改过
        // 如果stamp没有被修改过返回true，被修改过返回false。如果stamp为0，是返回false。
        if (!s1.validate(stamp)) { 
        	// 发现被修改了，这里使用readLock()获得悲观的读锁，并进一步读取数据。
        	// 如果当前对象正在被修改，则读锁的申请可能导致线程挂起。
            stamp = s1.readLock();
            try {
                // 重新读取x和y的值
                currentX = x;
                currentY = y;
            } finally {
                s1.unlockRead(stamp);//退出临界区,释放读锁
            }
        }
        return Math.sqrt(currentX * currentX + currentY * currentY);
    }
}

StampedLock可能出现的性能问题

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

参考资料

Java并发编程之美

Java锁详解之改进读写锁StampedLock

0%