专栏首页java金融有了CopyOnWrite为何又要有ReadWriteLock?

有了CopyOnWrite为何又要有ReadWriteLock?

引言

前文我们有介绍《看了CopyOnWriteArrayList后自己实现了一个CopyOnWriteHashMap》 关于CopyOnWrite容器的,但是它也有一些缺点:

  • 内存占用问题:因为CopyOnWrite的写时复制机制每次进行写操作的时候都会有两个数组对象的内存,如果这个数组对象占用的内存较大的话,如果频繁的进行写入就会造成频繁的Yong GCFull GC
  • 数据一致性问题CopyOnWrite容器只能保证数据的最终一致性,不能保证数据的实时一致性。读操作的线程可能不会立即读取到新修改的数据,因为修改操作发生在副本上。但最终修改操作会完成并更新容器所以这是最终一致性。当时有说到解决这两个缺点我们可以使用Collections.synchronizedList()来替代,找个无非就是对list的增删改查方法都加了synchronized实现。我们知道synchronized其实是一个独占锁 (排他锁),如果不知道什么是独占锁的可以看看这个文章《史上最全 Java 中各种锁的介绍》 里面基本上把java里面的锁都介绍完了。但是这样的话就会存在一个性能问题,如果对于读多写少的场景,每次读也要去获取锁,读完了之后再释放锁,这样就造成了每个读的请求都要进行获取锁,但是读的话并不会引起数据不安全,这样就会造成一个性能瓶颈。为了解决这个问题,就又出现了一种新的锁,读写锁(ReadWriteLock)。

什么是读写锁

根据名字我们也可以猜个大概,就是有两把锁,分别是读锁和写锁。读锁在同一时刻可以允许多个读线程获取,但是在写线程访问的时候,所有的读线程和其他写线程都会被阻塞。写锁同一时刻只能有一个写线程获取成功,其他都会被阻塞。读写锁实际维护了两把锁,一个读锁和一个写锁,通过读锁和写锁进行区分,在读多写少的情况下并发性比独占锁有了很大的提升。在java里面对读写锁的实现就是ReentrantReadWriteLock,它有以下特性:

  • 公平性选择:支持非公平性(默认)和公平的锁获取方式,吞吐量还是非公平优于公平;
  • 重入性:支持重入,读锁获取后能再次获取,写锁获取之后能够再次获取写锁,同时也能够获取读锁;
  • 锁降级:遵循获取写锁,获取读锁再释放写锁的次序,写锁能够降级成为读锁

ReentrantReadWriteLock 的使用

我们先从官网来个事例https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/locks/ReentrantReadWriteLock.html,看看它是如何使用的

 class RWDictionary {
   private final Map<String, Data> m = new TreeMap<String, Data>();
   private final ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();
   private final Lock r = rwl.readLock();
   private final Lock w = rwl.writeLock();

   public Data get(String key) {
     r.lock();
     try { return m.get(key); }
     finally { r.unlock(); }
   }
   public String[] allKeys() {
     r.lock();
     try { return m.keySet().toArray(); }
     finally { r.unlock(); }
   }
   public Data put(String key, Data value) {
     w.lock();
     try { return m.put(key, value); }
     finally { w.unlock(); }
   }
   public void clear() {
     w.lock();
     try { m.clear(); }
     finally { w.unlock(); }
   }
 }

这个使用起来还是非常简单明了的,跟ReentrantLock的用法基本一致,写的时候获取写锁,写完了释放写锁,读的时候获取读锁,读完了就释放读写。

读写锁的实现分析

我们知道ReentrantLock是通过state来控制锁的状态,以及前面所介绍的《Java高并发编程基础三大利器之Semaphore》《Java高并发编程基础三大利器之CountDownLatch》《Java高并发编程基础三大利器之CyclicBarrier》 都是通过state来进行实现的那ReentrantReadWriteLock毋庸置疑肯定也是通过AQSstate来实现的,不过state是一个int值它是如何来读锁和写锁的。

读写锁状态的实现分析

如果我们有看过线程池的源码,我们知道线程池的状态和线程数是通过一个int类型原子变量(高3位保存运行状态,低29位保存线程数)来控制的。同样的ReentrantReadWriteLock也是通过一个state的高16位和低16位来分别控制读的状态和写状态。

下面我们就来看看它是如何通过一个字段来实现读写分离的,

        static final int SHARED_SHIFT   = 16;
        static final int SHARED_UNIT    = (1 << SHARED_SHIFT);
        static final int MAX_COUNT      = (1 << SHARED_SHIFT) - 1;
        static final int EXCLUSIVE_MASK = (1 << SHARED_SHIFT) - 1;

        /** Returns the number of shared holds represented in count  */
        static int sharedCount(int c)    { return c >>> SHARED_SHIFT; }
        /** Returns the number of exclusive holds represented in count  */
        static int exclusiveCount(int c) { return c & EXCLUSIVE_MASK; }
  • sharedCount : 读锁数量 是将同步状态(int c)无符号右移16位,即取同步状态的高16位。
  • exclusiveCount:写锁数量 我们要看下EXCLUSIVE_MASK 这个静态变量:它是1进行左移16位然后减1也就是0X0000FFFF(1 << SHARED_SHIFT) - 1= 0X0000FFFF 所以exclusiveCount 就是相当于 c&0X0000FFFF 所以也就是低16位用来表示写锁的获取次数。

源码分析

基于jdk1.8 既然ReentrantReadWriteLock也是基于AQS来实现的,那么它肯定是重写了AQS的获取锁的方法,那我们就直接去ReentrantReadWriteLock这个类里面看看lock的地方我们先看看获取读锁的地方

  protected final boolean tryAcquire(int acquires) {
            /*
             * Walkthrough:
             * 1. If read count nonzero or write count nonzero
             *    and owner is a different thread, fail.
             * 2. If count would saturate, fail. (This can only
             *    happen if count is already nonzero.)
             * 3. Otherwise, this thread is eligible for lock if
             *    it is either a reentrant acquire or
             *    queue policy allows it. If so, update state
             *    and set owner.
             */
            Thread current = Thread.currentThread();
            // 获取写锁当前的同步状态
            int c = getState();
            // 写锁次数
            int w = exclusiveCount(c);
            if (c != 0) {
                // (Note: if c != 0 and w == 0 then shared count != 0)
                // 当前状态不为0,但是写锁为0 就说明读锁不为0
               // 当读锁已被读线程获取或者当前线程不是已经获取写锁的线程的话获取写锁失败
                if (w == 0 || current != getExclusiveOwnerThread())
                    return false;
                if (w + exclusiveCount(acquires) > MAX_COUNT)
                    throw new Error("Maximum lock count exceeded");
                // Reentrant acquire 获取到写锁
                setState(c + acquires);
                return true;
            }
               //writerShouldBlock 公平锁和非公平锁的判断
            if (writerShouldBlock() ||
                !compareAndSetState(c, c + acquires))
                return false;
            setExclusiveOwnerThread(current);
            return true;
        }

写锁完了,接下来肯定就是读锁了由于读锁是共享锁,所以也应该重写了tryAcquireShared 这个就不贴代码了,和读锁差不多这个就不做分析了。其实把AQS弄明白了再来看这些基于AQS来实现的玩意还是比较容易的。

读写锁的升级与降级

前面我们有提到读写锁是可以降级的,但是没有说是否可以升级。我们先看看什么是锁降级和锁升级

  • 锁降级:从写锁变成读锁;它的过程是先持有写锁,在获取读锁,再释放写锁。如果是持有写锁,释放写锁,再获取读锁这种情况不是锁降级。
  • 为什么要锁降级?

★主要是为了保证数据的可见性,如果当前线程不获取读锁而是直接释放写锁, 假设此刻另一个线程(记作线程T)获取了写锁并修改了数据,那么当前线程无法感知线程T的数据更新。如果当前线程获取读锁,即遵循锁降级的步骤,则线程T将会被阻塞,直到当前线程使用数据并释放读锁之后,线程T才能获取写锁进行数据更新。来源于《Java 并发编程的艺术》 ”

  • 锁升级:从读锁变成写锁。先持有读锁,再去获取写锁(这是不会成功的)因为获取写锁是独占锁,如果有读锁被占用了,写锁就会放入队列中等待,直至读锁全部被释放之后才有可能获取到写锁。

思考题

  • 本篇文章主要介绍了单机情况的读写锁,如果要实现一个分布式的读写锁该如何实现?
  • ReentrantReadWriteLock的饥饿问题如何解决?(ReentrantReadWriteLock实现了读写分离,想要获取读锁就必须确保当前没有其他任何读写锁了,但是一旦读操作比较多的时候,想要获取写锁就变得比较困难了,因为当前有可能会一直存在读锁。而无法获得写锁。)

结束

  • 由于自己才疏学浅,难免会有纰漏,假如你发现了错误的地方,还望留言给我指出来,我会对其加以修正。
  • 如果你觉得文章还不错,你的转发、分享、赞赏、点赞、留言就是对我最大的鼓励。
  • 感谢您的阅读,十分欢迎并感谢您的关注。

本文分享自微信公众号 - java金融(java4299),作者:java金融

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2021-04-27

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 为何有了组件, 还要有微服务?

    微服务其实真正要解決的问题是:过去在組件化架构上一直没法解決的问题…… 当将某組件佈署到 Production 的環境上時,如何能 “永远” 的不致於對已在 P...

    Ken Fang 方俊贤
  • 高性能与调优

    春哥大魔王
  • 为什么有了IndexOf,还要有FindIndex​?

    【摘要】对于IndexOf(),相信大家都是很熟悉的,但是,昨天我们提供的List用法中还有一个FindIndex(),看起来功能描述与IndexOf...

    高一峰
  • 有http,为何还要RPC!!!

    http是指从客户端到服务器端的请求消息,rpc是远程过程调用协议,它们之间有什么区别呢,下面是小编整理的相关内容,希望对大家有所帮助!

    A梦多啦A
  • 聊聊并发-Java中的Copy-On-Write容器

    Copy-On-Write简称COW,是一种用于程序设计中的优化策略。其基本思路是,从一开始大家都在共享同一个内容,当某个人想要修改这个内容的时候,才会真正把内...

    哲洛不闹
  • 有了 MySQL,为什么还要 NoSQL?

    这家公司的真名就叫做“三藏”,和我的名字“悟空”很契合,唐三藏给悟空面试,合情合理,还带有一丝趣味,所以我就去面试了。三藏公司是一家小厂,技术负责人面的我,欲知...

    悟空聊架构
  • CopyOnWrite 思想及其应用场景

    CopyOnWrite(简称COW,中文意思是:写入时复制)就是在进行写操作时,先复制要改变的对象,对副本进行写操作,完成对副本的操作后,把原有对象的引用指向副...

    飞狗
  • CopyOnWrite你都不知道还怎么拿Offer

    CopyOnWriteArrayList 是一个并发容器。有很多人称它是线程安全的,我认为这句话不严谨,缺少一个前提条件,那就是非复合场景下操作它是线程安全的...

    业余草
  • 为什么有了 MySQL ,还要有时序数据库?

    近日,UCloud新发布了一款时间序列数据库UTSDB (UCloud TimeSeries Database) ,此次上线的UTSDB-InfluxDB版基于...

    芋道源码
  • 已有Qemu了,为什么还要StratoVirt?

    1.目前 qemu已经有157万代码,而且其中又有很大一部分代码是用来支持legacy特性或者设备的,功能和设备严重耦合在一起,导致无法轻装上阵。

    虚拟化云计算
  • 有了 elseif 为什么还要 switch case

    你有没有想过既然有了if elseif, 为什么还要设计一个switch case的语法出来呢? 按理说, 一个语言的设计角度来说, 关键词越少越好吧, 而且多...

    烟草的香味
  • 有了container为什么还需要pod

    问题: 容器明明对标的是单个进程的概念,物理机里面进程不就是调度的最小单位了吗?为什么k8s还特意搞了一个pod出来?

    灰子学技术
  • Java集合--线程安全(CopyOnWrite机制)

    贾博岩
  • CopyOnWriteArrayList 源码解析

    我们知道 ArrayList 非线程安全,需要自己加锁或者使用 Collections.synchronizedList 包装.

    JavaEdge
  • 何为正则表达式?要他有何用?

    文章不好,作为学习,差不多就行了。 平常大家都会使用word,记事本之类的文字编辑软件,也会经常使用复制粘贴,把从知网下载下来的论文粘贴到自己的文章里面,一篇课...

    企鹅号小编
  • 详解CopyOnWrite容器及其源码

    在jave.util.concurrent包下有这样两个类:CopyOnWriteArrayList和CopyOnWriteArraySet。 其中利用到了Co...

    王金龙
  • 看完这篇CopyOnWriteArrayList源码解析,和阿里面试官扯了整整一个小时!

    我们知道 ArrayList 非线程安全,需要自己加锁或者使用 Collections.synchronizedList 包装. 从JDK1.5开始JUC里提...

    JavaEdge
  • Java 中的锁 (总结)

    像 乐观锁,悲观锁,互斥锁 等也都是 并发控制的机制,或者说是资源争用控制的机制。

    zhangyunfeiVir
  • Java的CopyOnWriteArrayList

    ArrayList并不是线程安全的,在读线程在读取ArrayList的时候如果有写线程在写数据的时候,基于fast-fail机制,会抛出ConcurrentMo...

    用户3467126

扫码关注云+社区

领取腾讯云代金券