ReentrantLock、ReentrantReadWriteLock、StampedLock讲解
13、ReentrantLock、ReentrantReadWriteLock、StampedLock讲解
![](/2022/06/10/ReentrantLock%E3%80%81ReentrantReadWriteLock%E3%80%81StampedLock%E8%AE%B2%E8%A7%A3/%E7%AB%A0%E8%8A%8213.png)
13.1 读写锁ReentrantReadWriteLock
13.1.1 读写锁说明
![](/2022/06/10/ReentrantLock%E3%80%81ReentrantReadWriteLock%E3%80%81StampedLock%E8%AE%B2%E8%A7%A3/1654830635958.png)
13.1.2 【读写锁】意义和特点
- 它只允许读读共存,而读写和写写依然是互斥的,大多实际场景是“读/读”线程间并不存在互斥关系,只有”读/写”线程或”写/写”线程间的操作需要互斥的。因此引入ReentrantReadWriteLock。
- 一个ReentrantReadWriteLock同时只能存在一个写锁但是可以存在多个读锁,但不能同时存在写锁和读锁(切菜还是拍蒜选一个)。也即一个资源可以被多个读操作访问或一个写操作访问,但两者不能同时进行。
- 只有在读多写少情景之下,读写锁才具有较高的性能体现。
13.1.3 code演示ReentrantReadwriteLockDemo
1 | class MyResource //资源类,模拟一个简单的缓存 |
13.1.4 《Java并发编程的艺术》中关于锁降级的说明
ReentrantReadWriteLock锁降级:将写入锁降级为读锁(类似Linux文件读写权限理解,就像写权限要高于读权限一样),锁的严苛程度变强叫做升级,反之叫做降级。
写锁的降级,降级成为了读锁。
- 如果同一个线程持有了写锁,在没有释放写锁的情况下,它还可以继续获得读锁。这就是写锁的降级,降级成为了读锁。
- 规则惯例,先获取写锁,然后获取读锁,再释放写锁的次序。
- 如果释放了写锁,那么就完全转换为读锁。
why?要有这么个特性?—-后面解释,设计思想见《Oracle公司ReentrantWriteReadLock源码总结》
- 锁降级中读锁的获取是否必要呢?答案是必要的。主要是为了保证数据的可见性,如果当前线程不获取读锁而是直接释放写锁, 假设此刻另一个线程(记作线程T)获取了写锁并修改了数据,那么当前线程无法感知线程T的数据更新。如果当前线程获取读锁,即遵循锁降级的步骤,则线程T将会被阻塞,直到当前线程使用数据并释放读锁之后,线程T才能获取写锁进行数据更新。
13.1.5 可以降级
锁降级:遵循获取写锁一再获取读锁一再释放写锁的次序,写锁能够降级成为读锁。如果一个线程占有了写锁,在不释放写锁的情况下,它还能占有读锁,即写锁降级为读锁。
13.1.6 code演示LockDownGradingDemo
1 | /** |
13.1.7 不可锁升级
![](/2022/06/10/ReentrantLock%E3%80%81ReentrantReadWriteLock%E3%80%81StampedLock%E8%AE%B2%E8%A7%A3/1654830888073.png)
![](/2022/06/10/ReentrantLock%E3%80%81ReentrantReadWriteLock%E3%80%81StampedLock%E8%AE%B2%E8%A7%A3/1654830894020.png)
1 | /** |
13.1.8 写锁和读锁是互斥的
写锁和读锁是互斥的(这里的互斥是指线程间的互斥,当前线程可以获取到写锁又获取到读锁,但是获取到了读锁不能继续获取写锁),这是因为读写锁要保持写操作的可见性。因为,如果允许读锁在被获取的情况下对写锁的获取,那么正在运行的其他读线程无法感知到当前写线程的操作。
因此,分析读写锁ReentrantReadWriteLock,会发现它有个潜在的问题:
- 读锁结束,写锁有望;写锁独占,读写全堵;
- 如果有线程正在读,写线程需要等待读线程释放锁后才能获取写锁,见前面Case《code演示LockDownGradingDemo》
即ReentrantReadWriteLock读的过程中不允许写,只有等待线程都释放了读锁,当前线程才能获取写锁,也就是写入必须等待,这是一种悲观的读锁,/(ㄒoㄒ)/~~,人家还在读着那,你先别去写,省的数据乱。
13.1.9 后续讲解StampedLock时再详细展开
- 分析StampedLock(后面详细讲解),会发现它改进之处在于:
- 读的过程中也允许获取写锁介入(相当牛B,读和写两个操作也让你“共享”(注意引号)),这样会导致我们读的数据就可能不一致。
- 所以,需要额外的方法来判断读的过程中是否有写入,这是一种乐观的读锁,O(∩_∩)O。
- 显然乐观锁的并发效率更高,但一旦有小概率的写入导致读取的数据不一致,需要能检测出来,再读一遍就行。
13.1.10 Oracle公司ReentrantWriteReadLock源码总结
锁降级,下面的示例代码摘自ReentrantWriteReadLock源码中:ReentrantWriteReadLock支持锁降级,遵循按照获取写锁,获取读锁再释放写锁的次序,写锁能够降级成为读锁,不支持锁升级。
- 代码中声明了一个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 | /** |
![](/2022/06/10/ReentrantLock%E3%80%81ReentrantReadWriteLock%E3%80%81StampedLock%E8%AE%B2%E8%A7%A3/1654831190675.png)
14、总结
![](/2022/06/10/ReentrantLock%E3%80%81ReentrantReadWriteLock%E3%80%81StampedLock%E8%AE%B2%E8%A7%A3/%E7%AB%A0%E8%8A%8214.png)
14.1 锁的到底是什么
![](/2022/06/10/ReentrantLock%E3%80%81ReentrantReadWriteLock%E3%80%81StampedLock%E8%AE%B2%E8%A7%A3/1654832022706.png)
- 作用于实例方法,当前实例加锁,进入同步代码前要获得当前实例的锁;
- 作用于代码块,对括号里配置的对象加锁。
- 作用于静态方法,当前类加锁,进去同步代码前要获得当前类对象的锁;
14.2 64位图
![](/2022/06/10/ReentrantLock%E3%80%81ReentrantReadWriteLock%E3%80%81StampedLock%E8%AE%B2%E8%A7%A3/1654832069165.png)
14.3 CAS的底层原理
![](/2022/06/10/ReentrantLock%E3%80%81ReentrantReadWriteLock%E3%80%81StampedLock%E8%AE%B2%E8%A7%A3/1654832100844.png)
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挂起、唤醒线程即可。
14.7 出队入队Node
![](/2022/06/10/ReentrantLock%E3%80%81ReentrantReadWriteLock%E3%80%81StampedLock%E8%AE%B2%E8%A7%A3/1654832236611.png)
AQS内部维护一个同步队列,元素就是包装了线程的Node。
同步队列中首节点是获取到锁的节点,它在释放锁的时会唤醒后继节点,后继节点获取到锁的时候,会把自己设为首节点。
线程会先尝试获取锁,失败则封装成Node,CAS加入同步队列的尾部。在加入同步队列的尾部时,会判断前驱节点是否是head结点,并尝试加锁(可能前驱节点刚好释放锁),否则线程进入阻塞等待。
14.8 ThreadLocal
- 当使用ThreadLocal声明变量时,ThreadLocal为每个使用该变量的线程提供独立的变量副本,每一个线程都可以独立地改变自己的副本,而不会影响其它线程所对应的副本。