👳我亲爱的各位大佬们好
♨️本篇文章记录的为 ReentrantReadWriteLock 相关内容，适合在学Java的小白,帮助新手快速上手,也适合复习中，面试中的大佬🙉🙉🙉。
♨️如果文章有什么需要改进的地方还请大佬不吝赐教❤️🧡💛
👨🔧 个人主页 : 阿千弟读写锁定义为： 一个资源能够被多个读线程访问，或者被一个写线程访问，但是不能同时存在读写线程。
@[toc]
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感兴趣的朋友,请多多关注💖💖💖
👨🔧 个人主页 : 阿千弟
