👳我亲爱的各位大佬们好
♨️本篇文章记录的为 ReentrantReadWriteLock 相关内容,适合在学Java的小白,帮助新手快速上手,也适合复习中,面试中的大佬🙉🙉🙉。
♨️如果文章有什么需要改进的地方还请大佬不吝赐教❤️🧡💛
👨🔧 个人主页 : 阿千弟
读写锁定义为: 一个资源能够被多个读线程访问,或者被一个写线程访问,但是不能同时存在读写线程。
文章目录
- 1、读写锁意义和特点
- 2、特点
- Lock 和 synchronized 的异同
- 3、从写锁→读锁,ReentrantReadWriteLock可以降级
- 1、读写锁降级演示
- 2、写锁和读锁是互斥的
1、读写锁意义和特点
读写锁ReentrantReadWriteLock并不是真正意义上的读写分离,它只允许读读共存,而读写和写写依然是互斥的, 大多实际场景是“读/读”线程间并不存在互斥关系,只有"读/写"线程或"写/写"线程间的操作需要互斥的。因此引入ReentrantReadWriteLock。
一个ReentrantReadWriteLock同时只能存在一个写锁但是可以存在多个读锁,但不能同时存在写锁和读锁。 也即一个资源可以被多个读操作访问或一个写操作访问,但两者不能同时进行。
只有在读多写少情境之下,读写锁才具有较高的性能体现。
2、特点
- 可重入
- 读写分离
Lock 和 synchronized 的异同
特性 | Lock | synchronized |
---|---|---|
本质 | Lock锁是接口 | synchronized是关键字 |
作用范围 | 只能作用于代码块上 | 作用于方法和代码块上 |
底层 | 基于AQS,FIFO先进先出队列实现的 | 基于objectMonitor对象锁来实现的 |
支持 | 支持公平锁和非公平锁 | 只支持非公平锁 |
加锁方式 | 非阻塞式加锁,并且支持可中断式加锁,支持超时时间加锁 | 阻塞式加锁 |
加锁和解锁 | Lock锁有一个同步队列和支持多个等待队列(condition) | 在加锁和解锁时,只有一个同步队列和一个等待队列 |
等待和唤醒 | lock锁使用的是condition接口的await()和signal()方法 | 使用的是object类中的wait()和notify()方法 |
3、从写锁→读锁,ReentrantReadWriteLock可以降级
《Java 并发编程的艺术》中关于锁降级的说明:
锁的严苛程度变强叫做升级,反之叫做降级
锁降级:将写入锁降级为读锁(类似Linux文件读写权限理解,就像写权限要高于读权限一样)
1、读写锁降级演示
可以降级
锁降级:遵循获取写锁→再获取读锁→再释放写锁的次序,写锁能够降级成为读锁。 如果一个线程占有了写锁,在不释放写锁的情况下,它还能占有读锁,即写锁降级为读锁。
Java8 官网说明
重入还允许通过获取写入锁定,然后读取锁然后释放写锁从写锁到读取锁, 但是,从读锁定升级到写锁是不可能的。
锁降级是为了让当前线程感知到数据的变化,目的是保证数据可见性
/**
* 锁降级:遵循获取写锁→再获取读锁→再释放写锁的次序,写锁能够降级成为读锁。
*
* 如果一个线程占有了写锁,在不释放写锁的情况下,它还能占有读锁,即写锁降级为读锁。
*/
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();
}
}
如果有线程在读,那么写线程是无法获取写锁的,是悲观锁的策略
不可锁升级
线程获取读锁是不能直接升级为写入锁的。
在ReentrantReadWriteLock中,当读锁被使用时,如果有线程尝试获取写锁,该写线程会被阻塞。所以,需要释放所有读锁,才可获取写锁,
2、写锁和读锁是互斥的
写锁和读锁是互斥的(这里的互斥是指线程间的互斥,当前线程可以获取到写锁又获取到读锁,但是获取到了读锁不能继续获取写锁),这是因为读写锁要保持写操作的可见性。因为,如果允许读锁在被获取的情况下对写锁的获取,那么正在运行的其他读线程无法感知到当前写线程的操作
因此,分析读写锁ReentrantReadWriteLock,会发现它有个潜在的问题:读锁全完,写锁有望;写锁独占,读写全堵;如果有线程正在读,写线程需要等待读线程释放锁后才能获取写锁,见前面Case《code演示LockDownGradingDemo》即ReadWriteLock读的过程中不允许写,只有等待线程都释放了读锁,当前线程才能获取写锁,也就是写入必须等待,这是一种悲观的读锁,o(╥﹏╥)o,人家还在读着那,你先别去写,省的数据乱。
分析StampedLock(后面详细讲解),会发现它改进之处在于:读的过程中也允许获取写锁介入(相当牛B,读和写两个操作也让你“共享”(注意引号)),这样会导致我们读的数据就可能不一致! 所以,需要额外的方法来判断读的过程中是否有写入,这是一种乐观的读锁,O(∩_∩)O哈哈~。 显然乐观锁的并发效率更高,但一旦有小概率的写入导致读取的数据不一致,需要能检测出来,再读一遍就行。
如果这篇【文章】有帮助到你💖,希望可以给我点个赞👍,创作不易,如果有对
Java后端
或者对spring
感兴趣的朋友,请多多关注💖💖💖
👨🔧 个人主页 : 阿千弟