本文主要内容：读写锁的理论；通过生活中例子来理解读写锁；读写锁的代码演示；读写锁总结。通过理论(总结)-例子-代码-然后再次总结，这四个步骤来让大家对读写锁的深刻理解。
在Java并发包中常用的锁（如：ReentrantLock），基本上都是排他锁，这些锁在同一时刻只允许一个线程进行访问，而读写锁在同一时 刻可以允许多个读线程访问，但是在写线程访问时，所有的读线程和其他写线程均被阻塞。读写锁维护了一对锁，一个读锁和一个写锁，通过分离读锁和写锁，使得 并发性相比一般的排他锁有了很大提升。
Java 并发包中的读写锁及其实现分析 1. 前言 在Java并发包中常用的锁（如：ReentrantLock），基本上都是排他锁，这些锁在同一时刻只允许一个线程进行访问，而读写锁在同一时 刻可以允许多个读线程访问，但是在写线程访问时，所有的读线程和其他写线程均被阻塞。读写锁维护了一对锁，一个读锁和一个写锁，通过分离读锁和写锁，使得 并发性相比一般的排他锁有了很大提升。 除了保证写操作对读操作的可见性以及并发性的提升之外，读写锁能够简化读写交互场景的编程方式。假设在程序中定义一个共享的数据结构用作缓存，它大
现实中有这样一种场景：对共享资源有读和写的操作，且写操作没有读操作那么频繁。在没有写操作的时候，多个线程同时读一个资源没有任何问题，所以应该允许多个线程同时读取共享资源；但是如果一个线程想去写这些共享资源，就不应该允许其他线程对该资源进行读和写的操作了。 针对这种场景，JAVA 的并发包提供了读写锁 ReentrantReadWriteLock，它表示两个锁，一个是读操作相关的锁，称为共享锁；一个是写相关的锁，称为排他锁。 线程进入读锁的条件：
3、ReadWriteLock是读写锁，它是一个界面，RentrantReadWriteLock实现了这个界面。
非公平性锁可能使线程“饥饿”，为什么它又被设定成默认的实现呢？再次观察上表的结 果，如果把每次不同线程获取到锁定义为1次切换，公平性锁在测试中进行了10次切换，而非 公平性锁只有5次切换，这说明非公平性锁的开销更小。
之前提到的ReentrantLock是排他锁，这种锁同一时刻只允许一个线程访问，而读写锁同一时刻可以多个线程访问，但在写线程访问时，所有读线程和其他写线程都要被阻塞。读写锁维护了一对锁，一个读锁和一个写锁，通过分离读写锁，使得并发性相比一般的排他锁有很大提升。
锁是用来控制多个线程访问共享资源的方式，一般来说锁能够防止多个线程同时访问共享资源（有的锁可以允许多个线程访问共享资源，比如说读写锁），在Lock接口出现之前，java程序是靠synchronized关键字实现锁功能的，但是在JKD1.5之后并发包中新增了Lock接口及其实现来实现锁的功能。它提供了synchronized关键字类似的功能，但是Lock需要显示的获取锁、释放锁，而synchronized是通过隐式的方式来实现获取、释放锁。
前文我们有介绍《看了CopyOnWriteArrayList后自己实现了一个CopyOnWriteHashMap》 关于CopyOnWrite容器的，但是它也有一些缺点：
通过以下几部分来分析Java提供的读写锁ReentrantReadWriteLock：
在Java高级的并发包里面还有一个有用的同步工具，就是 ReadWriteLock读写锁，它本身是一个接口，注意这个接口并没有继承Lock接口，因为的它的功能比较特殊，所以单独成为一个接口，我们经常需要使用它下面的子类： ReentrantReadWriteLock。
最近我又双叒叕写了个BUG，一个线上服务死锁了，不过幸亏是个新服务，没有什么大影响。
重入锁ReentrantLock是排他锁，排他锁在同一时刻仅有一个线程可以进行访问，但是在大多数场景下，大部分时间都是提供读服务，而写服务占有的时间较少。然而读服务不存在数据竞争问题，如果一个线程在读时禁止其他线程读势必会导致性能降低。所以就提供了读写锁。 读写锁维护着一对锁，一个读锁和一个写锁。通过分离读锁和写锁，使得并发性比一般的排他锁有了较大的提升：在同一时间可以允许多个读线程同时访问，但是在写线程访问时，所有读线程和写线程都会被阻塞。 读写锁的主要特性： 公平性：支持公平性和非公平性。 重入性：支持
Java提供了许多功能强大的工具和技术，用于实现并发编程和解决资源争夺问题。在本文中，下面将介绍一些常用的Java并发编程概念、技术和解决方案。
10.ReadWriteLock 读写锁 读-写锁 ReadWriteLock - ReadWriteLock 维护了一对相关的锁，一个用于只读操作，另一个用于写入操作。只要没有 writer，读取锁可以由多个 reader 线程同时保持。写入锁是独占的。。 - ReadWriteLock 读取操作通常不会改变共享资源，但执行写入操作时，必须独占方式来获取锁。对于读取操作占多数的数据结构。ReadWriteLock 能提供比独占锁更高的并发性。而对于只读的数据结构，其中包含的不变性可以完全不需要考虑加锁操
如下图，tomcat 接收到到请求后，依次调用控制器 Controller、服务层 Service 、数据库访问层的相关方法。
我们开发中应该能够遇到这样的一种情况，对共享资源有读和写的操作，且写操作没有读操作那么频繁。在没有写操作的时候，多个线程同时读一个资源没有任何问题，所以应该允许多个线程同时读取共享资源；但是当一个写者线程在写这些共享资源时，就不允许其他线程进行访问。
在Java并发编程中，实现锁的方式有两种，分别是：可以使用同步锁(synchronized关键字的锁)，还有lock接口下的锁。从今天起，凯哥将带领大家一起豪华参观(详细讲解)在Java并发包(JUC)下locks包下的体系结构。
读写锁（Readers-Writer Lock）顾名思义是一把锁分为两部分：读锁和写锁，其中读锁允许多个线程同时获得，因为读操作本身是线程安全的，而写锁则是互斥锁，不允许多个线程同时获得写锁，并且写操作和读操作也是互斥的。总结来说，读写锁的特点是：读读不互斥、读写互斥、写写互斥。
go语言类似Java JUC包也提供了一些列用于多线程之间进行同步的措施，比如低级的同步措施有 锁、CAS、原子变量操作类。相比Java来说go提供了独特的基于通道的同步措施。本节我们先来看看go中读写锁
大家好，我是三友，这篇文章想来跟大家来探讨一下，在Java中已经提供了并发安全的集合，为什么有的场景还需要使用读写锁，直接用并发安全的集合难道不行么？
关于读写锁里面有一个锁升级和降级的问题，也就是写锁可以降级为读锁，但是读锁却不能升级为写锁。那么为什么是这样？
本文主要分享 Eureka 注册中心的那把读写锁，让我瘙痒难耐，却不得其解。在某次意外的抠脚的一刻( 笔者不抽烟，如果抽烟的话，此处应该就不是抠脚了 )，突然顿悟，爽，这好比… 比喻有点猥琐，笔者就省略 100 字。
锁是多线程并发问题中的重要组成，接着上一篇文章，今天就简单总结一下Java中各种锁如何分类。
今天我要给大家分享一些自己日常学习到的一些知识点，并以文字的形式跟大家一起交流，互相学习，一个人虽可以走的更快，但一群人可以走的更远。
先说明下，本文要讨论的多线程读写是指一个线程写，一个或多个线程读，不包括多线程同时写的情况。
这也是为啥默认是非公平锁的原因（一般情况下，非公平锁的性能高于公平锁） 那什么时候应该用公平锁呢？
开发中遇到并发的问题一般会用到锁，Synchronized存在明显的一个性能问题就是读与读之间互
读写锁定义： 一个资源能够被多个读线程访问，或者被一个写线程访问，但是不能同时存在读写线程。
可重入锁，也叫递归锁。它有两层含义，第一，当一个线程在外层函数得到可重入锁后，能直接递归地调用该函数，第二，同一线程在外层函数获得可重入锁后，内层函数可以直接获取该锁对应其它代码的控制权。之前我们提到的synchronized和ReentrantLock都是可重入锁。
Java读写锁，也就是ReentrantReadWriteLock，其包含了读锁和写锁，其中读锁是可以多线程共享的，即共享锁，而写锁是排他锁，在更改时候不允许其他线程操作。读写锁底层是同一把锁（基于同一个AQS），所以会有同一时刻不允许读写锁共存的限制。
重入锁ReentrantLock，顾名思义，就是支持重进入的锁，它表示该锁能够支持一个线程对 资源的重复加锁，而不会造成自己阻塞自己。
现实中有这样一种场景：对共享资源有读和写的操作，且写操作没有读操作那 么频繁。在没有写操作的时候，多个线程同时读一个资源没有任何问题，所以 应该允许多个线程同时读取共享资源；但是如果一个线程想去写这些共享资源， 就不应该允许其他线程对该资源进行读和写的操作了。
乐观锁是一种乐观思想，即认为读多写少，遇到并发写的可能性低，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，采取在写时先读出当前版本号，然后加锁操作（比较跟上一次的版本号，如果一样则更新），如果失败则要重复读-比较-写的操作。 Java中的乐观锁基本都是通过CAS操作实现的，CAS是一种更新的原子操作，比较当前值跟传入值是否一样，一样则更新，否则失败。
最近是和java.util.concurrent.locks包下的同步类干上了，素有 并发根基 之称的concurrent包中全是精品，今天我们继续哈，今天学习的主题要由一个大厂常问的Java面试题开始：
读写锁在 Java 中是 ReentrantReadWriteLock，使用方式是：
如果锁具备可重入性，则称作为可重入锁。像synchronized和ReentrantLock都是可重入锁，可重入性在我看来实际上表明了锁的分配机制：基于线程的分配，而不是基于方法调用的分配。举个简单的例子，当一个线程执行到某个synchronized方法时，比如说method1，而在method1中会调用另外一个synchronized方法method2，此时线程不必重新去申请锁，而是可以直接执行方法method2。
https://segmentfault.com/a/1190000010895869
接下来几篇文章会对JUC并发包里面的锁工具类做下梳理，如：ReentrantLock、
之前的Synchronized和ReentrantLock都是排他锁,默认只有一个线程可以占用
Lock 是相当于 synchronized 更面向对象的同步方式，ReentrantLock 是 Lock 的实现。
乐观锁是一种乐观思想，假定当前环境是读多写少，遇到并发写的概率比较低，读数据时认为别的线程不会正在进行修改（所以没有上锁）。写数据时，判断当前 与期望值是否相同，如果相同则进行更新（更新期间加锁，保证是原子性的）。
a)Java中的锁——Lock和synchronized中介绍的ReentrantLock和synchronized基本上都是排它锁，意味着这些锁在同一时刻只允许一个线程进行访问，而读写锁在同一时刻可以允许多个读线程访问，在写线程访问的时候其他的读线程和写线程都会被阻塞。读写锁维护一对锁(读锁和写锁)，通过锁的分离，使得并发性提高。
广义上可重入锁，也叫做递归锁，指的是同一线程，外层函数获得锁之后，内层函数仍有获得该锁的代码，但不受影响。Java的ReentrantLock和synchronized都是可重入锁。
现在都是“大数据”时代，大量的用户数据需要处理，如何保证大量数据在多线程下的安全，成了比较重要的问题。
用syn也可以实现原子操作不过不太合适，目前CPU指令级别实现了原子性的比较和交换（Conmpare And Swap）操作(CAS不是锁只是CPU提供的一个原子性操作指令哦切记)。
前面介绍了java中排它锁，共享锁的底层实现机制，本篇再进一步，学习非常有用的读写锁。鉴于读写锁比其他的锁要复杂，不想堆一大波的文字，本篇会试图图解式说明，把读写锁的机制用另外一种方式阐述，鉴于本人水平有限，如果哪里有误，请不吝赐教。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
云直播
