༺歲月蹉跎༻

只要路是对的,就不怕路远!

0%

ReentrantLock、ReentrantReadWriteLock、StampedLock讲解

13、ReentrantLock、ReentrantReadWriteLock、StampedLock讲解

13.1 读写锁ReentrantReadWriteLock

13.1.1 读写锁说明

1654830635958

13.1.2 【读写锁】意义和特点

  • 它只允许读读共存,而读写和写写依然是互斥的,大多实际场景是“读/读”线程间并不存在互斥关系,只有”读/写”线程或”写/写”线程间的操作需要互斥的。因此引入ReentrantReadWriteLock。
  • 一个ReentrantReadWriteLock同时只能存在一个写锁但是可以存在多个读锁,但不能同时存在写锁和读锁(切菜还是拍蒜选一个)。也即一个资源可以被多个读操作访问或一个写操作访问,但两者不能同时进行。
  • 只有在读多写少情景之下,读写锁才具有较高的性能体现。

13.1.3 code演示ReentrantReadwriteLockDemo

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
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
class MyResource //资源类,模拟一个简单的缓存
{
Map<String, String> map = new HashMap<>();
//=====ReentrantLock 等价于 =====synchronized,之前讲解过
Lock lock = new ReentrantLock();
//=====ReentrantReadWriteLock 一体两面,读写互斥,读读共享
ReadWriteLock rwLock = new ReentrantReadWriteLock();

public void write(String key, String value) {
rwLock.writeLock().lock();
try {
System.out.println(Thread.currentThread().getName() + "\t" + "正在写入");
map.put(key, value);
//暂停毫秒
try {
TimeUnit.MILLISECONDS.sleep(500);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println(Thread.currentThread().getName() + "\t" + "完成写入");
} finally {
rwLock.writeLock().unlock();
}
}

public void read(String key) {
rwLock.readLock().lock();
try {
System.out.println(Thread.currentThread().getName() + "\t" + "正在读取");
String result = map.get(key);
//暂停200毫秒
//try { TimeUnit.MILLISECONDS.sleep(200); } catch (InterruptedException e) { e.printStackTrace(); }

//暂停2000毫秒,演示读锁没有完成之前,写锁无法获得
try {
TimeUnit.MILLISECONDS.sleep(2000);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println(Thread.currentThread().getName() + "\t" + "完成读取" + "\t" + result);
} finally {
rwLock.readLock().unlock();
}
}


}


/**
* @auther zzyy
* @create 2022-04-08 18:18
*/
public class ReentrantReadWriteLockDemo {
public static void main(String[] args) {
MyResource myResource = new MyResource();

for (int i = 1; i <= 10; i++) {
int finalI = i;
new Thread(() -> {
myResource.write(finalI + "", finalI + "");
}, String.valueOf(i)).start();
}

for (int i = 1; i <= 10; i++) {
int finalI = i;
new Thread(() -> {
myResource.read(finalI + "");
}, String.valueOf(i)).start();
}

//暂停几秒钟线程
try {
TimeUnit.SECONDS.sleep(1);
} catch (InterruptedException e) {
e.printStackTrace();
}

for (int i = 1; i <= 3; i++) {
int finalI = i;
new Thread(() -> {
myResource.write(finalI + "", finalI + "");
}, "新写锁线程->" + String.valueOf(i)).start();
}
}
}

13.1.4 《Java并发编程的艺术》中关于锁降级的说明

  • ReentrantReadWriteLock锁降级:将写入锁降级为读锁(类似Linux文件读写权限理解,就像写权限要高于读权限一样),锁的严苛程度变强叫做升级,反之叫做降级。

    1654830723798

  • 写锁的降级,降级成为了读锁。

    • 如果同一个线程持有了写锁,在没有释放写锁的情况下,它还可以继续获得读锁。这就是写锁的降级,降级成为了读锁。
    • 规则惯例,先获取写锁,然后获取读锁,再释放写锁的次序。
    • 如果释放了写锁,那么就完全转换为读锁。
  • why?要有这么个特性?—-后面解释,设计思想见《Oracle公司ReentrantWriteReadLock源码总结》

    • 锁降级中读锁的获取是否必要呢?答案是必要的。主要是为了保证数据的可见性,如果当前线程不获取读锁而是直接释放写锁, 假设此刻另一个线程(记作线程T)获取了写锁并修改了数据,那么当前线程无法感知线程T的数据更新。如果当前线程获取读锁,即遵循锁降级的步骤,则线程T将会被阻塞,直到当前线程使用数据并释放读锁之后,线程T才能获取写锁进行数据更新。

13.1.5 可以降级

  • 锁降级:遵循获取写锁一再获取读锁一再释放写锁的次序,写锁能够降级成为读锁。如果一个线程占有了写锁,在不释放写锁的情况下,它还能占有读锁,即写锁降级为读锁。

    1654830793872

    1654830799357

13.1.6 code演示LockDownGradingDemo

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
/**
* @auther zzyy
* 锁降级:遵循获取写锁→再获取读锁→再释放写锁的次序,写锁能够降级成为读锁。
* <p>
* 如果一个线程占有了写锁,在不释放写锁的情况下,它还能占有读锁,即写锁降级为读锁。
* <p>
* 读没有完成时候写锁无法获得锁,必须要等着读锁读完后才有机会写
*/
public class LockDownGradingDemo {
public static void main(String[] args) {
ReentrantReadWriteLock readWriteLock = new ReentrantReadWriteLock();

ReentrantReadWriteLock.ReadLock readLock = readWriteLock.readLock();
ReentrantReadWriteLock.WriteLock writeLock = readWriteLock.writeLock();

writeLock.lock();
System.out.println("----写入");

readLock.lock();
System.out.println("----读取");

writeLock.unlock();

readLock.unlock();
}
}

13.1.7 不可锁升级

1654830888073

1654830894020

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
/**
* @auther zzyy
* 锁降级:遵循获取写锁→再获取读锁→再释放写锁的次序,写锁能够降级成为读锁。
*
* 如果一个线程占有了写锁,在不释放写锁的情况下,它还能占有读锁,即写锁降级为读锁。
*
* 读没有完成时候写锁无法获得锁,必须要等着读锁读完后才有机会写
*/
public class LockDownGradingDemo
{
public static void main(String[] args)
{
ReentrantReadWriteLock readWriteLock = new ReentrantReadWriteLock();

ReentrantReadWriteLock.ReadLock readLock = readWriteLock.readLock();
ReentrantReadWriteLock.WriteLock writeLock = readWriteLock.writeLock();

readLock.lock();
System.out.println("----读取");

writeLock.lock();
System.out.println("----写入");

writeLock.unlock();
readLock.unlock();

}
}

13.1.8 写锁和读锁是互斥的

  • 写锁和读锁是互斥的(这里的互斥是指线程间的互斥,当前线程可以获取到写锁又获取到读锁,但是获取到了读锁不能继续获取写锁),这是因为读写锁要保持写操作的可见性。因为,如果允许读锁在被获取的情况下对写锁的获取,那么正在运行的其他读线程无法感知到当前写线程的操作。

  • 因此,分析读写锁ReentrantReadWriteLock,会发现它有个潜在的问题:

    • 读锁结束,写锁有望;写锁独占,读写全堵;
    • 如果有线程正在读,写线程需要等待读线程释放锁后才能获取写锁,见前面Case《code演示LockDownGradingDemo》
  • 即ReentrantReadWriteLock读的过程中不允许写,只有等待线程都释放了读锁,当前线程才能获取写锁,也就是写入必须等待,这是一种悲观的读锁,/(ㄒoㄒ)/~~,人家还在读着那,你先别去写,省的数据乱。

13.1.9 后续讲解StampedLock时再详细展开

  • 分析StampedLock(后面详细讲解),会发现它改进之处在于:
    • 读的过程中也允许获取写锁介入(相当牛B,读和写两个操作也让你“共享”(注意引号)),这样会导致我们读的数据就可能不一致。
    • 所以,需要额外的方法来判断读的过程中是否有写入,这是一种乐观的读锁,O(∩_∩)O。
    • 显然乐观锁的并发效率更高,但一旦有小概率的写入导致读取的数据不一致,需要能检测出来,再读一遍就行。

13.1.10 Oracle公司ReentrantWriteReadLock源码总结

  • 锁降级,下面的示例代码摘自ReentrantWriteReadLock源码中:ReentrantWriteReadLock支持锁降级,遵循按照获取写锁,获取读锁再释放写锁的次序,写锁能够降级成为读锁,不支持锁升级。

    1654831027298

    • 代码中声明了一个volatile类型的cacheValid变量,保证其可见性。
    • 首先获取读锁,如果cache不可用,则释放读锁。获取写锁,在更改数据之前,再检查一次cacheValid的值,然后修改数据,将cacheValid置为true,然后在释放写锁前立刻抢夺获取读锁;此时,cache中数据可用,处理cache中数据,最后释放读锁。这个过程就是一个完整的锁降级的过程,目的是保证数据可见性。
  • 总结:一句话,同一个线程自己持有写锁时再去拿读锁,其本质相当于重入。

  • 如果违背锁降级的步骤,如果当前的线程C在修改完cache中的数据后,没有获取读锁而是直接释放了写锁,那么假设此时另一个线程D获取了写锁并修改了数据,那么C线程无法感知到数据已被修改,则数据出现错误。

13.2 邮戳锁StampedLock

13.2.1 锁饥饿问题

  • ReentrantReadWriteLock实现了读写分离,但是一旦读操作比较多的时候,想要获取写锁就变得比较困难了,假如当前1000个线程,999个读,1个写,有可能999个读取线程长时间抢到了锁,那1个写线程就悲剧了
    因为当前有可能会一直存在读锁,而无法获得写锁,根本没机会写,/(ㄒoㄒ)/~~。

13.2.2 Why闪亮

  • ReentrantReadWriteLock

    • 允许多个线程同时读,但是只允许一个线程写,在线程获取到写锁的时候,其他写操作和读操作都会处于阻塞状态,读锁和写锁也是互斥的,所以在读的时候是不允许写的,读写锁比传统的synchronized速度要快很多,原因就是在于ReentrantReadWriteLock支持读并发,读读可以共享。
  • StampedLock横空出世

    • ReentrantReadWriteLock的读锁被占用的时候,其他线程尝试获取写锁的时候会被阻塞。但是,StampedLock采取乐观获取锁后,其他线程尝试获取写锁时不会被阻塞,这其实是对读锁的优化,所以,在获取乐观读锁后,还需要对结果进行校验。

13.2.3 乐观读模式code演示

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
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
/**
* @auther zzyy
* <p>
* StampedLock = ReentrantReadWriteLock + 读的过程中也允许获取写锁介入
*/
public class StampedLockDemo {
static int number = 37;
static StampedLock stampedLock = new StampedLock();

public void write() {
long stamp = stampedLock.writeLock();
System.out.println(Thread.currentThread().getName() + "\t" + "写线程准备修改");
try {
number = number + 13;
} finally {
stampedLock.unlockWrite(stamp);
}
System.out.println(Thread.currentThread().getName() + "\t" + "写线程结束修改");
}

//悲观读,读没有完成时候写锁无法获得锁
public void read() {
long stamp = stampedLock.readLock();
System.out.println(Thread.currentThread().getName() + "\t" + " come in readlock code block,4 seconds continue...");
for (int i = 0; i < 4; i++) {
//暂停几秒钟线程
try {
TimeUnit.SECONDS.sleep(1);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println(Thread.currentThread().getName() + "\t" + " 正在读取中......");
}

try {
int result = number;
System.out.println(Thread.currentThread().getName() + "\t" + " 获得成员变量值result:" + result);
System.out.println("写线程没有修改成功,读锁时候写锁无法介入,传统的读写互斥");
} finally {
stampedLock.unlockRead(stamp);
}
}

//乐观读,读的过程中也允许获取写锁介入
public void tryOptimisticRead() {
long stamp = stampedLock.tryOptimisticRead();
int result = number;
//故意间隔4秒钟,很乐观认为读取中没有其它线程修改过number值,具体靠判断
System.out.println("4秒前stampedLock.validate方法值(true无修改,false有修改)" + "\t" + stampedLock.validate(stamp));
for (int i = 0; i < 4; i++) {
try {
TimeUnit.SECONDS.sleep(1);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println(Thread.currentThread().getName() + "\t" + "正在读取... " + i + " 秒" +
"后stampedLock.validate方法值(true无修改,false有修改)" + "\t" + stampedLock.validate(stamp));
}
if (!stampedLock.validate(stamp)) {
System.out.println("有人修改过------有写操作");
stamp = stampedLock.readLock();
try {
System.out.println("从乐观读 升级为 悲观读");
result = number;
System.out.println("重新悲观读后result:" + result);
} finally {
stampedLock.unlockRead(stamp);
}
}
System.out.println(Thread.currentThread().getName() + "\t" + " finally value: " + result);
}


public static void main(String[] args) {
StampedLockDemo resource = new StampedLockDemo();

/*传统版
new Thread(() -> {
resource.read();
},"readThread").start();

//暂停几秒钟线程
try { TimeUnit.SECONDS.sleep(1); } catch (InterruptedException e) { e.printStackTrace(); }

new Thread(() -> {
System.out.println(Thread.currentThread().getName()+"\t"+"----come in");
resource.write();
},"writeThread").start();

//暂停几秒钟线程
try { TimeUnit.SECONDS.sleep(4); } catch (InterruptedException e) { e.printStackTrace(); }

System.out.println(Thread.currentThread().getName()+"\t"+"number:" +number);*/

new Thread(() -> {
resource.tryOptimisticRead();
}, "readThread").start();

//暂停2秒钟线程,读过程可以写介入,演示
//try { TimeUnit.SECONDS.sleep(2); } catch (InterruptedException e) { e.printStackTrace(); }

//暂停6秒钟线程
try {
TimeUnit.SECONDS.sleep(6);
} catch (InterruptedException e) {
e.printStackTrace();
}

new Thread(() -> {
System.out.println(Thread.currentThread().getName() + "\t" + "----come in");
resource.write();
}, "writeThread").start();
}
}

1654831190675

14、总结

14.1 锁的到底是什么

1654832022706

  • 作用于实例方法,当前实例加锁,进入同步代码前要获得当前实例的锁;
  • 作用于代码块,对括号里配置的对象加锁。
  • 作用于静态方法,当前类加锁,进去同步代码前要获得当前类对象的锁;

14.2 64位图

1654832069165

14.3 CAS的底层原理

1654832100844

14.4 ABA问题

  • 问题:
    • 线程X准备将变量的值从A改为B,然而这期间线程Y将变量的值从A改为C,然后再改为A;最后线程X检测变量值是A,并置换为B。
    • 但实际上,A已经不再是原来的A了解决方法,是把变量定为唯一类型。值可以加上版本号,或者时间戳。
  • 解决:
    • 如加上版本号,线程Y的修改变为A1->B2->A3,此时线程X再更新则可以判断出A1不等于A3。

14.5 LockSupport.park和Object.wait区别

  • 线程在Object.wait之后必须等到Object.notify才能唤醒。

  • LockSupport可以先unpark线程,等线程执行LockSupport.park是不会挂起的,可以继续执行。

  • LockSupport是基于Unsafe类,由JDK提供的线程操作工具类,主要作用就是挂起线程,唤醒线程。

14.6 AQS是什么

  • volatile+cas机制实现的锁模板,保证了代码的同步性和可见性,而AQS封装了线程阻塞等待挂起,解锁唤醒其他线程的逻辑。AQS子类只需根据状态变量,判断是否可获取锁,是否释放锁,使用LockSupport挂起、唤醒线程即可。

    1654832213620

14.7 出队入队Node

1654832236611

  • AQS内部维护一个同步队列,元素就是包装了线程的Node。

  • 同步队列中首节点是获取到锁的节点,它在释放锁的时会唤醒后继节点,后继节点获取到锁的时候,会把自己设为首节点。

  • 线程会先尝试获取锁,失败则封装成Node,CAS加入同步队列的尾部。在加入同步队列的尾部时,会判断前驱节点是否是head结点,并尝试加锁(可能前驱节点刚好释放锁),否则线程进入阻塞等待。

14.8 ThreadLocal

  • 当使用ThreadLocal声明变量时,ThreadLocal为每个使用该变量的线程提供独立的变量副本,每一个线程都可以独立地改变自己的副本,而不会影响其它线程所对应的副本。