Java并发原理抽丝剥茧,读写锁ReadWriteLock实现深入剖析

推荐阅读:

关于读写锁

前面的章节中我们分析了Java语法层面的synchronized锁和JDK内置可重入锁ReentrantLock,我们在多线程并发场景中可以通过它们来控制对资源的访问从而达到线程安全。这两种锁都属于纯粹的独占锁,也就是说这些锁任意时刻只能由一个线程持有,其它线程都得排队依次获取锁。

有些场景下为了提高并发性能我们会对纯粹的独占锁进行改造,额外引入共享锁来与独占锁共同对外构成一个锁,这种就叫读写锁。为什么叫读写锁呢?主要是因为它的使用考虑了读写场景,一般认为读操作不会改变数据所以可以多线程进行读操作,但写操作会改变数据所以只能一个线程进行写操作。读写锁在内部维护了一对锁(读锁和写锁),它通过将锁进行分离从而得到更高的并发性能。

如下图中,存在一个读写锁对象,其内部包含了读锁和写锁两个对象。假如存在五个线程,其中线程一和线程二想要获取读锁,那么两个线程是可以同时获取到读锁的。但是写锁就不可以共享,它是独占锁。比如线程三、线程四和线程五都想要持有写锁,那么只能一个个线程轮着持有。

读写锁

读写锁的性质

  • 可以多个线程同时持有读锁,某个线程成功获取读锁后其它线程仍然能成功获取读锁,即使该线程不释放读锁。

读写锁性质1

  • 在某个线程持有读锁的情况下其它线程不能持有写锁,除非持有读锁的线程全部都释放掉读锁。

读写锁性质2

  • 在某个线程持有写锁的情况下其它线程不能持有写锁或读锁,某个线程成功获取写锁后其它所有尝试获取读锁和写锁的线程都将进入等待状态,只有当该线程释放写锁后才其它线程能够继续往下执行。

读写锁性质3

  • 如果我们要获取读锁则需要满足两个条件:目前没有线程持有写锁和目前没有线程请求获取写锁。

读写锁性质4

  • 如果我们要获取写锁则需要满足两个条件:目前没有线程持有写锁和目前没有线程持有读锁。

读写锁性质5

简单的实现版本

为了加深对读写锁的理解,在分析JDK实现的读写锁之前我们先来看一个简单的读写锁实现版本。其中三个整型变量分别表示持有读锁的线程数、持有写锁的线程数以及请求获取写锁的线程数,四个方法分别对应读锁、写锁的获取和释放操作。acquireReadLock方法用于获取读锁,如果持有写锁的线程数量或请求读锁的线程数大于0则让线程进入等待状态。releaseReadLock方法用于释放读锁,将读锁线程数减一并唤醒其它线程。acquireWriteLock方法用于获取写锁,如果持有读锁的线程数量或持有写锁的线程数量大于0则让线程进入等待状态。releaseWriteLock方法用于释放写锁,将写锁线程数减一并唤醒其它线程。

读写锁简单版本

读锁升级为写锁

在某些场景下,我们希望某个已经拥有读锁的线程能够获得写锁,并将原来的读锁释放掉,这种情况就涉及到读锁升级为写锁操作。读写锁的升级操作需要满足一定的条件,这个条件就是某个线程必须是唯一拥有读锁的线程,否则将无法成功升级。如下图中,线程二已经持有读锁了,而且它是唯一的一个持有读锁的线程,所以它可以成功获得写锁。

读锁升级

写锁降级为读锁

与锁升级相对应的是锁降级,锁降级就是某个已经拥有写锁的线程希望能够获得读锁,并将原来的写锁释放掉。锁降级操作几乎没有什么风险,因为写锁是独占锁,持有写锁的线程肯定是唯一的,而且读锁也肯定不存在持有线程,所以写锁可以直接降级为读锁。如下图中,线程三持有写锁,此时其它线程不可能持有读锁和写锁,所以可以安全地将写锁降为读锁。

写锁降级

ReadWriteLock接口

ReadWriteLock实际上是一个接口,它仅仅提供了两个方法:readLock和writeLock。分别表示获取读锁对象和获取写锁对象,JDK为我们提供了一个内置的读写锁工具,那就是ReentrantReadWriteLock类,我们将对其进行深入分析。ReentrantReadWriteLock类包含的属性和方法较多,为了让分析思路清晰且方便读者理解,我们将剔除非核心源码,只对核心功能进行分析。

ReentrantReadWriteLock三要素

ReentrantReadWriteLock类的三要素为:公平/非公平模式、读锁对象和写锁对象。其中公平/非公平模式表示多个线程同时去获取锁时是否按照先到先得的顺序获得锁,如果是则为公平模式,否则为非公平模式。读锁对象负责实现读锁功能,而写锁对象负责实现写锁功能,这两个类都属于ReentrantReadWriteLock的内部类,下面会详细讲解。

ReentrantReadWriteLock实现思想

总的来说,ReentrantReadWriteLock类的内部包含了ReadLock内部类和WriteLock内部类,分别对应读锁和写锁,这两种锁都提供了公平模式和非公平模式。不管公平模式还是非公平模式、不管是读锁还是写锁都是基于AQS同步器来实现的。实现的主要难点在于只使用一个AQS同步器对象来实现读锁和写锁,这就要求读锁和写锁共用同一个共享状态变量,下面会具体讲解如何用一个状态变量来供读锁和写锁使用。

实现思想

对应ReentrantReadWriteLock类的结构如下,ReentrantReadWriteLock.ReadLock和ReentrantReadWriteLock.WriteLock分别为读锁对象和写锁对象。Sync对象表示ReentrantReadWriteLock类的同步器,它基于AQS同步器,而FairSync类和NonfairSync类分别表示公平模式和非公平模式的同步器,可以看到默认情况下使用的是非公平模式。

读写锁共用状态变量

前面提到过ReentrantReadWriteLock的难点在于读锁和写锁都共用一个共享变量,下面看具体是如何共用的。我们知道AQS同步器的共享状态是整型的,即32位,那么最简单的共用方式就是读锁和写锁分别使用16位。其中高16位用于读锁的状态,而低16位则用于写锁的状态,这样便达到共用效果。但是这样设计后当我们要获取读锁和写锁的状态值时则需要一些额外的计算,比如一些移位和逻辑与操作。

共用状态变量

ReentrantReadWriteLock的同步器共用状态变量的逻辑如下,其中SHARED_SHIFT表示移动的位数为16;SHARED_UNIT表示读锁每次加锁对应的状态值大小,1左移16位刚好对应高16位的1;MAX_COUNT表示读锁能被加锁的最大次数,值为16个1(二进制);EXCLUSIVE_MASK表示写锁的掩码,值为16个1(二进制)。sharedCount方法用于获取读锁(高16位)的状态值,左移16位即能得到。exclusiveCount方法用于获取写锁(低16位)的状态值,通过掩码即能得到。

ReadLock与WriteLock简介

ReadLock与WriteLock是ReentrantReadWriteLock的两个要素,它们都属于ReentrantReadWriteLock的内部类。它们都实现了Lock接口,我们主要关注lock、unlock和newCondition这几个核心方法。分别表示对读锁和写锁的加锁操作、释放锁操作和创建Condition对象操作,可以看到这些方法都间接调用了ReentrantReadWriteLock的同步器的方法,需要注意的是读锁不支持创建Condition对象。我们在可重入锁ReentrantLock章节中已经讲解过Condition对象,本节将不再赘述。

公平/非公平模式

ReentrantReadWriteLock的默认模式为非公平模式,其内部类Sync是公平模式FairSync类和非公平模式NonfairSync类的抽象父类。因为ReentrantReadWriteLock的读锁使用了共享模式,而写锁使用了独占模式,所以该父类将不同模式下的公平机制抽象成readerShouldBlock和writerShouldBlock两个抽象方法,然后子类就可以各自实现不同的公平模式。换句话说,ReentrantReadWriteLock的公平机制就由这两个方法来决定了。

下面看公平模式的FairSync类,该类的readerShouldBlock和writerShouldBlock两个方法都直接返回hasQueuedPredecessors方法的结果,这个方法是AQS同步器的方法,用于判断当前线程前面是否有排队的线程。如果有排队队列就要让当前线程也加入排队队列中,这样按照队列顺序获取锁也就保证了公平性。

继续看非公平模式NonfairSync类,该类的writerShouldBlock方法直接返回false,表明不要让当前线程进入排队队列中,直接进行锁的获取竞争。readerShouldBlock方法则调用apparentlyFirstQueuedIsExclusive方法,这个方法是AQS同步器的方法,用于判断头结点的下一个节点线程是否在请求获取独占锁(写锁)。如果是则让其它线程先获取写锁,而自己则乖乖去排队。如果不是则说明下一个节点线程是请求共享锁(读锁),此时直接与之竞争读锁。

公平/非公平

写锁WriteLock的实现

上面的介绍中我们知道WriteLock有两个核心方法:lock和unlock。它们都会间接调用了ReentrantReadWriteLock内部同步器的对应方法,在同步器中需要重写tryAcquire方法和tryRelease方法,分别用于获取写锁和释放写锁操作。

先看tryAcquire方法的逻辑,获取状态值并通过exclusiveCount方法得到低16位的写锁状态值。c!=0时有两种情况,一种是高16位的读锁状态不为0,一种是低16位的写锁状态不为0。w等于0时表示还有线程持有读锁,直接返回false表示获取写锁失败。如果持有写锁的线程为当前线程,则表示写锁重入操作,此时需要将状态变量进行累加,此外需要校验的是写锁重入状态值不能超过MAX_COUNT。通过writerShouldBlock方法判断是否需要将当前线程放入排队队列中,同时通过拥有CAS算法的compareAndSetState方法对状态变量进行累加操作,CAS失败的话也需要将当前线程放入排队队列中。对于非公平模式,这里的CAS操作就是闯入操作,即线程先尝试一次竞争写锁。最后通过setExclusiveOwnerThread设置当前线程持有写锁,该方法只是简单的设置变量方法。

继续看tryRelease方法的逻辑,先用isHeldExclusively方法检查当前线程必须为写锁持有线程。然后将状态值减去释放的值,并通过exclusiveCount得到低16位的写锁状态值,如果其值为0则表示已经没有重入可以彻底释放锁了,调用setExclusiveOwnerThread(null)设置没有线程持有写锁。最后设置新的状态值。

读锁ReadLock的实现

ReadLock同样有两个核心方法:lock和unlock。它们都会间接调用了ReentrantReadWriteLock内部同步器的对应方法,在同步器中需要重写tryAcquireShared方法和tryReleaseShared方法,分别用于获取读锁和释放读锁操作。

tryAcquireShared方法的逻辑为:先通过getState方法获取状态值,然后通过exclusiveCount方法获取低16位的写锁状态,如果不为0则表示有其它线程持有写锁而且当前线程没有持有写锁,则此时尝试获取读锁失败,返回-1,即将当前线程放到排队队列。注意这里如果当前线程持有写锁的话则可以继续获取读锁。继续通过sharedCount得到高16位的读锁,然后尝试用CAS算法设置新的状态值,如果成功则返回1表示成功获取读锁。如果不成功则继续调用fullTryAcquireShared方法。

fullTryAcquireShared方法的逻辑为:这是一个无限自旋操作,首先获取状态值,如果写锁不为0且当前线程不为持有写锁程序,则返回-1,表示尝试获取读锁失败,将当前线程加入排队队列中。如果写锁的状态为0,则表示没有线程持有写锁,继续通过readerShouldBlock方法判断是否需要将该线程加入到排队队列中,如果需要则返回-1,AQS同步器会将其加入到排队队列中。此外,读锁的状态值不能等于MAX_COUNT,即已经达到最大读锁数了。最后,通过CAS算法的compareAndSetState方法设置新的状态值,这里的for无限循环就是自旋,指通过自旋方式来竞争读锁。需要注意的是,在非公平模式下如果排队队列中下一个线程是要获取写锁,则这个自旋操作也会被打破。

tryReleaseShared方法的逻辑为:通过for无限循环实现自旋,自旋的逻辑就是不断计算新的状态值,然后通过CAS算法的compareAndSetState方法来设置新的状态值。

例子

如下是一个读写锁的使用例子,我们实例化了一个ReentrantReadWriteLock对象,然后通过它的读锁和写锁来控制对某个线程不安全的TreeMap对象的访问。我们可以看到get方法属于读取数据的操作,所以使用共享的读锁即可。而put和clear两个方法涉及到修改数据的操作,需要使用独占的写锁。

例子

总结

本文介绍了Java中的读写锁ReentrantReadWriteLock,从名字上看就知道它具有可重入性且提供了读写锁的功能。我们讲解了它的核心三要素以及实现原理。在ReentrantReadWriteLock读写锁中,写锁是一种独占锁,包括了公平模式和非公平模式。而读写则是一种共享锁,它也包含了公平模式和非公平模式。ReentrantReadWriteLock类的实现基于AQS同步器,其中最重要的点是它通过某些技巧让读锁和写锁公共了同一个状态变量,高16位与低16位。通过本文的讲解相信大家已经很好地掌握了JDK提供的读写锁的实现原理。

作者:超人汪小建

Spring全套教学资料

Spring是Java程序员的《葵花宝典》,其中提供的各种大招,能简化我们的开发,大大提升开发效率!目前99%的公司使用了Spring,大家可以去各大招聘网站看一下,Spring算是必备技能,所以一定要掌握。

资料领取方式:点击这里前往蓝色传送门

目录:

部分内容:

Spring源码

  • 第一部分 Spring 概述
  • 第二部分 核心思想
  • 第三部分 手写实现 IoC 和 AOP(自定义Spring框架)
  • 第四部分 Spring IOC 高级应用
    基础特性
    高级特性
  • 第五部分 Spring IOC源码深度剖析
    设计优雅
    设计模式
    注意:原则、方法和技巧
  • 第六部分 Spring AOP 应用
    声明事务控制
  • 第七部分 Spring AOP源码深度剖析
    必要的笔记、必要的图、通俗易懂的语言化解知识难点

脚手框架:SpringBoot技术

它的目标是简化Spring应用和服务的创建、开发与部署,简化了配置文件,使用嵌入式web服务器,含有诸多开箱即用的微服务功能,可以和spring cloud联合部署。

Spring Boot的核心思想是约定大于配置,应用只需要很少的配置即可,简化了应用开发模式。

  • SpringBoot入门
  • 配置文件
  • 日志
  • Web开发
  • Docker
  • SpringBoot与数据访问
  • 启动配置原理
  • 自定义starter

微服务架构:Spring Cloud Alibaba

同 Spring Cloud 一样,Spring Cloud Alibaba 也是一套微服务解决方案,包含开发分布式应用微服务的必需组件,方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。

  • 微服务架构介绍
  • Spring Cloud Alibaba介绍
  • 微服务环境搭建
  • 服务治理
  • 服务容错
  • 服务网关
  • 链路追踪
  • ZipKin集成及数据持久化
  • 消息驱动
  • 短信服务
  • Nacos Confifig—服务配置
  • Seata—分布式事务
  • Dubbo—rpc通信

Spring MVC

目录:

部分内容:

Spring MVC

目录:

[外链图片转存中…(img-KG2ni4Ci-1623566933473)]

[外链图片转存中…(img-OW4crGEG-1623566933474)]

[外链图片转存中…(img-Y2ECMzHC-1623566933475)]

部分内容:

[外链图片转存中…(img-dUNRPPxI-1623566933475)]

[外链图片转存中…(img-6Ma9Or54-1623566933476)]

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值