java源码 - ReentrantReadWriteLock读锁介绍

最新推荐文章于 2024-04-06 17:52:48 发布
最新推荐文章于 2024-04-06 17:52:48 发布
阅读量81 收藏
点赞数
文章标签： java 数据结构与算法
原文链接：https://yq.aliyun.com/articles/666308
版权

开篇

  • 这篇文章主要从源码角度讲解ReentrantReadWriteLock的ReadLock的加锁和减锁过程。

  • ReentrantReadWriteLock的ReadLock加锁解锁过程依赖于AQS类，所以有些相同的逻辑可以看看ReentrantLock的逻辑。

  • ReentrantReadWriteLock的ReadLock的唤醒过程具备传播性：
    假设按照顺序A->B->C->D占用读锁，唤醒会依次进行
    A线程占用读锁被唤醒后，A线程的锁释放会唤醒B线程。
    B线程占用读锁被唤醒后，B线程的锁释放会唤醒C线程。
    C线程占用读锁被唤醒后，C线程的锁释放会唤醒D线程。


加锁过程

  • ReadLock的lock()内部通过sync. acquireShared(1)获取锁。
  • acquireShared()方法内部先通过tryAcquireShared尝试获取锁。
  • 如果获锁失败执行doAcquireShared()方法加入等待队列。
    public void lock() {
        sync.acquireShared(1);
    }

    public final void acquireShared(int arg) {
        if (tryAcquireShared(arg) < 0)
            doAcquireShared(arg);
    }



tryAcquireShared过程

  • 如果当前锁写状态不为0且占锁线程非当前线程，那么返回占锁失败的值-1。
  • 如果公平策略没有要求阻塞且重入数没有到达最大值，则直接尝试cas更新state。
  • 如果cas操作成功，有以下操作逻辑：
  • 首先，如果当前读锁计数为0那么就设置第一个读线程就是当前线程。
  • 其次，当前线程和firstReader同一个线程，记录firstReaderHoldCount也就是第一个读线程读锁定次数。
  • 最后，读锁数量不为0并且不为当前线程，获取当前线程ThreadLocal当中的读锁重入计数器。
  • 结果返回占锁成功的值1
  • 如果cas操作失败，有以下操作逻辑：
  • 通过fullTryAcquireShared尝试获取读锁，内部处理和tryAcquireShared过程相同。
    protected final int tryAcquireShared(int unused) {
        Thread current = Thread.currentThread();
        int c = getState();
        // 如果当前锁写状态不为0且占锁线程非当前线程，那么返回占锁失败。
        // 也就是当前线程先占写锁后可以再占读锁的，反之不行。
        if (exclusiveCount(c) != 0 &&
            getExclusiveOwnerThread() != current)
            return -1;
        // 判断高位的读状态标记
        int r = sharedCount(c);
        //如果公平策略没有要求阻塞且重入数没有到达最大值，则直接尝试CAS更新state
        //如果读不应该阻塞并且读锁的个数小于最大值65535，并且可以成功更新状态值
        if (!readerShouldBlock() &&
            r < MAX_COUNT &&
            compareAndSetState(c, c + SHARED_UNIT)) {

            // 如果当前线程满足对state的操作条件，
            // 就利用CAS设置state+SHARED_UNIT,实际上就是读状态+1。
            // 但是需要注意，这个state是全局的，即所有线程获取读锁次数的总和，
            // 而为了方便计算本线程的读锁次数以及释放掉锁，
            // 需要在ThreadLocal中维护一个变量。这就是HoldCounter。
        
            //如果当前读锁为0
            if (r == 0) {
                // 第一个读线程就是当前线程
                firstReader = current;
                firstReaderHoldCount = 1;
            } 
            //如果当前线程重入了，记录firstReaderHoldCount
            else if (firstReader == current) {
                firstReaderHoldCount++;
            } 
            //当前读线程和第一个读线程不同,记录每一个线程读的次数
            else {
                // 每个线程自己维护cachedHoldCounter
                HoldCounter rh = cachedHoldCounter;
                // 计数器为空或者计数器的tid不为当前正在运行的线程的tid
                if (rh == null || rh.tid != getThreadId(current))
                    cachedHoldCounter = rh = readHolds.get();
                else if (rh.count == 0)
                    readHolds.set(rh);
                rh.count++;
            }
            return 1;
        }

        //用来处理CAS没成功的情况，逻辑和上面的逻辑是类似的，就是加了无限循环
        return fullTryAcquireShared(current);
    }



fullTryAcquireShared过程

  • fullTryAcquireShared内部通过for()循环进行逻辑操作。
  • 内部处理和tryAcquireShared过程相同。
    final int fullTryAcquireShared(Thread current) {
        HoldCounter rh = null;
        // 无限循环
        for (;;) {
            // 获取状态
            int c = getState();
            // 写线程数量不为0且当前线程不是写线程那么返回获锁失败
            if (exclusiveCount(c) != 0) {
                if (getExclusiveOwnerThread() != current)
                    return -1;
            } 
            // 写线程数量为0并且读线程被阻塞
            else if (readerShouldBlock()) {
                if (firstReader == current) {
                    // 当前线程为第一个读线程
                    // assert firstReaderHoldCount > 0;
                } else {
                    // 当前线程不为第一个读线程
                    if (rh == null) {
                        rh = cachedHoldCounter;
                        if (rh == null || rh.tid != getThreadId(current)) {
                            rh = readHolds.get();
                            if (rh.count == 0)
                                readHolds.remove();
                        }
                    }
                    if (rh.count == 0)
                        return -1;
                }
            }
            // 读锁数量为最大值，抛出异常
            if (sharedCount(c) == MAX_COUNT)
                throw new Error("Maximum lock count exceeded");
             // 比较并且设置成功，后续的这部分逻辑跟之前讲的一模一样
            if (compareAndSetState(c, c + SHARED_UNIT)) {
                if (sharedCount(c) == 0) {
                    firstReader = current;
                    firstReaderHoldCount = 1;
                } else if (firstReader == current) {
                    firstReaderHoldCount++;
                } else {
                    if (rh == null)
                        rh = cachedHoldCounter;
                    if (rh == null || rh.tid != getThreadId(current))
                        rh = readHolds.get();
                    else if (rh.count == 0)
                        readHolds.set(rh);
                    rh.count++;
                    cachedHoldCounter = rh; // cache for release
                }
                return 1;
            }
        }
    }



doAcquireShared过程

  • doAcquireShared主要实现获读锁失败后的等待操作。
  • doAcquireShared通过addWaiter(Node.SHARED)将当前线程封装成SHARED类型Node并添加到CLH队列。
  • 如果当前线程的Node节点是CLH队列的第一个节点则当前线程直接获取锁并开启读锁的扩散唤醒所有阻塞读锁的线程。
  • 如果当前线程的Node节点不是CLH队列的第一个节点那么就通过parkAndCheckInterrupt进入休眠
  • doAcquireShared的内部的自旋保证了线程被唤醒后再次判断是否是第一个节点并尝试获取锁，失败再次进入休眠。
    private void doAcquireShared(int arg) {
        final Node node = addWaiter(Node.SHARED);
        boolean failed = true;
        try {
            boolean interrupted = false;
            // 开始自旋重试
            for (;;) {
                // 获取当前线程代表节点的前一个节点
                final Node p = node.predecessor();
                // 如果前一个节点是head节点(head节点不保存任何线程)，
                // 表明当前节点是第一个等待唤醒节点
                if (p == head) {
                    // 尝试获取锁
                    int r = tryAcquireShared(arg);
                    // 如果获锁成功
                    if (r >= 0) {
                        // 说明当前线程获取读锁成功，那么设置当前线程Node为head
                        // 同时扩散唤醒相关读线程，因为读线程之间相互不阻塞，可以一起唤醒继续工作
                        setHeadAndPropagate(node, r);
                        p.next = null; // help GC
                        if (interrupted)
                            selfInterrupt();
                        failed = false;
                        return;
                    }
                }
                // 如果“当前线程”不是CLH队列的表头，
                // 则通过shouldParkAfterFailedAcquire()判断是否需要等待，
                // 需要的话，则通过parkAndCheckInterrupt()进行阻塞等待。
                // 若阻塞等待过程中，线程被中断过，则设置interrupted为true。
                if (shouldParkAfterFailedAcquire(p, node) &&
                    parkAndCheckInterrupt())
                    interrupted = true;
            }
        } finally {
            if (failed)
                cancelAcquire(node);
        }
    }



setHeadAndPropagate过程

  • 设置当前线程的Node为CLH队列的head节点
  • 判断当前节点的后置节点为空或者是SHARED状态那么就唤起后置的读锁阻塞线程。
  • doReleaseShared在解锁过程也同样提及，放到后面解释。
    private void setHeadAndPropagate(Node node, int propagate) {
        // 设置当前节点为新的head节点
        Node h = head; 
        setHead(node);
       
        // 如果还有剩余量，继续唤醒下一个邻居线程
        if (propagate > 0 || h == null || h.waitStatus < 0 ||
            (h = head) == null || h.waitStatus < 0) {
            // 当前节点的后置节点
            Node s = node.next;
            if (s == null || s.isShared())
                // 唤醒后起等待线程
                doReleaseShared();
        }
    }


解锁过程

  • ReadLock的unlock()方法调用sync.releaseShared(1)方法进行释放。
  • 调用tryReleaseShared()方法尝试释放锁，如果释放成功，调用doReleaseShared尝试唤醒下一个节点
    public void unlock() {
        sync.releaseShared(1);
    }

    public final boolean releaseShared(int arg) {
        if (tryReleaseShared(arg)) {
            doReleaseShared();
            return true;
        }
        return false;
    }



tryReleaseShared过程

  • 如果是第一个读线程则修改firstReaderHoldCount，如果不是则修改局部HoldCounter。
  • for循环的死循环当中释放一把锁并设置全局锁状态state。
    protected final boolean tryReleaseShared(int unused) {
        // 得到调用unlock的线程
        Thread current = Thread.currentThread();
        
        //如果是第一个获得读锁的线程，进行解锁
        if (firstReader == current) {
            // assert firstReaderHoldCount > 0;
            if (firstReaderHoldCount == 1)
                firstReader = null;
            else
                firstReaderHoldCount--;
        } 
        // 否则，线程ThreadLocal的HoldCounter中计数-1
        else {
            HoldCounter rh = cachedHoldCounter;
            if (rh == null || rh.tid != getThreadId(current))
                rh = readHolds.get();
            int count = rh.count;
            if (count <= 1) {
                readHolds.remove();
                if (count <= 0)
                    throw unmatchedUnlockException();
            }
            --rh.count;
        }
      
        // 死循环
        for (;;) {
            int c = getState();
            // 释放一把读锁
            int nextc = c - SHARED_UNIT;
            // 如果CAS更新状态成功，返回读锁是否等于0；失败的话，则重试
            if (compareAndSetState(c, nextc))
                return nextc == 0;
        }
    }



doReleaseShared过程

  • 如果当前节点状态为SIGNAL，那么就通过unparkSuccessor()方法唤醒后置等待线程
  • 成功后则跳出for循环
    private void doReleaseShared() {
        for (;;) {
            Node h = head;
            if (h != null && h != tail) {
                // 当前节点为SIGNAL那么就需要通过unparkSuccessor(p)唤醒后置等待线程
                int ws = h.waitStatus;
                if (ws == Node.SIGNAL) {
                    if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
                        continue;            // loop to recheck cases
                    unparkSuccessor(h);
                }
                else if (ws == 0 &&
                         !compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
                    continue;                // loop on failed CAS
            }
            // 跳出循环
            if (h == head)                   // loop if head changed
                break;
        }
    }

    private void unparkSuccessor(Node node) {

        int ws = node.waitStatus;
        if (ws < 0)
            compareAndSetWaitStatus(node, ws, 0);

        Node s = node.next;
        if (s == null || s.waitStatus > 0) {
            s = null;
            for (Node t = tail; t != null && t != node; t = t.prev)
                if (t.waitStatus <= 0)
                    s = t;
        }
        if (s != null)
            LockSupport.unpark(s.thread);
    }


参考文章

探索 JUC 之美
轻松掌握java读写锁(ReentrantReadWriteLock)的实现原理

weixin_33734785
关注
Java并发--ReentrantReadWriteLock饥饿问题
星仔的博客
08-11 2070
前言 通过阅读ReentrantReadWriteLock的源码我们会发现ReentrantReadWriteLock内部通过AbstractQueuedSynchronizer来实现同步语义，在ReentrantReadWriteLock中拥有读锁与写锁。读锁是一种共享锁，允许多个线程同时获取锁，写锁是一种独占锁，同一时刻只允许一个线程获取。如果在读多写少的情况下，利用ReentrantReadWriteLock很容易造成饥饿问题。 饥饿问题：ReentrantReadWriteLock实现了读写分离
ReentrantReadWriteLock读锁作用
一百度的风的博客
08-02 333
为什么要有读锁
ReentrantReadWriteLock acquireShared源码分析
johnhuster的专栏
08-19 872
public final void acquireShared(int arg) { if (tryAcquireShared(arg) < 0) doAcquireShared(arg); } //该方法不会阻塞，该方法只是尝试获取而已，获取失败后就会调用doAcquireShared，...
深入理解AQS之ReentrantReadWriteLock详解
xjk201的博客
11-26 410
读写锁介绍 现实中有这样一种场景：对共享资源有读和写的操作，且写操作没有读操作那么频繁（读多写少）。在没有写操作的时候，多个线程同时读一个资源没有任何问题，所以应该允许多个线程同时读取共享资源（读读可以并发）；但是如果一个线程想去写这些共享资源，就不应该允许其他线程对该资源进行读和写操作了（读写，写读，写写互斥）。在读多于写的情况下，读写锁能够提供比排它锁更好的并发性和吞吐量。 针对这种场景，JAVA的并发包提供了读写锁ReentrantReadWriteLock，它内部，维护了一对相关的锁，一个用
java 共享锁_Java concurrency之共享锁和ReentrantReadWriteLock_动力节点Java学院整理
weixin_34691461的博客
02-16 149
ReadWriteLock 和 ReentrantReadWriteLock介绍ReadWriteLock，顾名思义，是读写锁。它维护了一对相关的锁 — — “读取锁”和“写入锁”，一个用于读取操作，另一个用于写入操作。“读取锁”用于只读操作，它是“共享锁”，能同时被多个线程获取。“写入锁”用于写入操作，它是“独占锁”，写入锁只能被一个线程锁获取。注意：不能同时存在读取锁和写入锁！ReadWrit...
ReentrantReadWriteLock读写锁
m0_56054652的博客
11-04 2712
一、前言 ReentrantReadWriteLock中包含三种锁：读写锁、可重入锁、公平/非公平锁 1、读写锁 2、可重入锁： 又名递归锁，是指在同一个线程在外层方法获取锁的时候，在进入内层方法会自动获取锁。说的有点抽象，下面会有一个代码的示例。 对于Java ReetrantLock而言，从名字就可以看出是一个重入锁，其名字是Re entrant Lock 重新进入锁。 对于Synchronized而言，也是一个可重入锁。可重入锁的一个好处是可一定程度避免死锁。 syn...
ReentrantReadWriteLock-读写锁
qq_41868309的博客
05-28 215
读写锁 读写锁的概念 之前提到锁，基本都是排他锁（如ReentrantLock）。这些锁在同一时刻只允许一个线程进行访问，而读写锁在同一时刻可以允许多个线程访问，但是在写线程访问时，所有的读线程和其他写线程均被阻塞。读写锁维护了一对锁，一个读锁和一个写锁，通过分离读锁和写锁，使得并发性比一般的排它锁有了很大提升。 除了保证写操作对读操作的可见性以及并发性的提升之外，读写锁能够简化读写交互场景的编程方式。假设在程序中定义一个共享的用作缓存数据结构，它大部分时间提供读服务（例如查询和搜索），而写操作占有的时间很
计算机软件-商业源码-利用读写锁保持线程同步.zip
05-23
- **读锁**：当一个线程获取读锁时，其他线程也可以同时获取读锁，因为读操作通常是非破坏性的。这意味着多个线程可以并发地读取同一数据而不会互相干扰。 - **写锁**：写锁是独占的，一旦一个线程获取了写锁，...
读写锁-ReentrantReadWriteLock源码分析与图解
Java框架、并发编程、分布式、微服务、Redis、HarmonyOS、中间件等技术
06-24 457
有经典，有干货，微信搜索【李子捌】关注这个每日推送经典的程序员。 为何要有读写锁 ReentrantLock锁和其他锁基本上都是排他锁，排他锁指的是在同一时刻只允许一个线程持有锁，访问共享资源。虽然ReentrantLock支持同一个线程重入，但是允许重入的是同一个线程。因此ReentrantReadWriteLock是为了支持多个线程在同一个时刻对于锁的访问孕育而生的。 读写锁—简单介绍 读写锁ReentrantReadWriteLock允许多个线程在同一时刻对于锁的访问。但是，写线程获取写锁时.
jdk1.8 J.U.C并发源码阅读------ReentrantReadWriteLock源码解析
勤劳的小蜜蜂啊~
08-02 897
jdk1.8中java.util.concurrent包中源码阅读笔记。
ReentrantReadWriteLock源码详解
qq_40276626的博客
08-22 278
读写锁我们都不陌生，多个线程可以同时拥有读锁，而同时只有一个线程拥有写锁，并且写锁和读锁是冲突的。 ReentrantReadWriteLock就是依据AQS实现的一个读写锁。 ReentrantReadWriteLock
ReentrantReadWriteLock——读写锁原理
最新发布
weixin_44689901的博客
04-06 968
用的是同一个Sycn同步器，因此等待队列,state等也是使用同一个t1成功上锁，流程与ReentrantLock加锁相比没有特殊之处，是写锁使用state的低16位，而读锁占了state的高16位。
ReentrantReadWriteLock难点分析
简单，快乐，拥抱变化
03-30 156
reentrantReadWriteLock难点分析
Java多线程系列--“JUC锁”08之 共享锁和ReentrantReadWriteLock
weixin_42073629的博客
01-27 142
ReadWriteLock 和 ReentrantReadWriteLock介绍 ReadWriteLock，顾名思义，是读写锁。它维护了一对相关的锁 — — “读取锁”和“写入锁”，一个用于读取操作，另一个用于写入操作。 “读取锁”用于只读操作，它是“共享锁”，能同时被多个线程获取。 “写入锁”用于写入操作，它是“独占锁”，写入锁只能被一个线程锁获取。 注意：不能同时存在读取锁和写入锁！ Re...
图文深入解析 JAVA 读写锁，为什么读锁套写锁会死锁，反过来却不会？
chongshizhuo8736的博客
06-13 2391
一、回顾基本的读写锁 我们知道读写锁 #java.util.concurrent.locks.ReentrantReadWriteLock 是一个 “读写互斥，写写互斥，读读共享” 的锁。 读写锁的使用非常简单，那就是： 我们只需要保证读锁和写锁来自同一个 ReentrantReadWrit...
深入理解读写锁—ReadWriteLock源码分析
热门推荐
xingfeng_coder的博客
04-24 7万+
ReadWriteLock管理一组锁，一个是只读的锁，一个是写锁。读锁可以在没有写锁的时候被多个线程同时持有，写锁是独占的。 所有读写锁的实现必须确保写操作对读操作的内存影响。换句话说，一个获得了读锁的线程必须能看到前一个释放的写锁所更新的内容。 读写锁比互斥锁允许对于共享数据更大程度的并发。每次只能有一个写线程，但是同时可以有多个线程并发地读数据。ReadWriteLock适用于读多写少的并发
【＜ J.U.C＞】
徐明晓的博客
08-05 406
这里写目录标题【< J.U.C>】[1] AQS[2] ReentrantLock[3] ReentrantReadWriteLock[4] StampedLock[5] Semaphore[6] threadlocal[7] CountDownLatch[8] CyclicBarrier？[9] Atmoic[10] FutureTask[11] ForkJoin 【< J.U.C>】 [1] AQS 见专题 [2] ReentrantLock 见专题 [3] ReentrantR
ReentrantReadWriteLock 底层原理
JH灰色的博客
07-02 743
文章目录1.读写锁自定义2. ReentrantReadWriteLock底层原理2.1. t1 w.lock，t2 r.lock2.1.1. 写锁上锁流程(跟ReentrantLock一样，t1 w.lock是独占锁/排它锁)2.1.2. 读锁上锁流程(t2 r.lock共享锁)2.2 t3 r.lock，t4 w.lock2.3 写锁释放(t1 w.unlock)2.3.1 写锁释放流程及读锁加锁流程2.4 t2 r.unlock，t3 r.unlock2.4.1 读锁释放流程与写锁加锁流程3. Ree
读写锁ReentrantReadWriteLock解析
一切的困难都来自于自己内心的恐惧
11-27 242
概要 读写锁中，读与写、写与写是互斥的，而 读与读 不是互斥的，所以读写锁在执行写操作的线程没有获得锁的情况下，执行读操作的线程可以多个线程都拥有锁。因此读写锁在存在大量读操作的情况下比普通锁的效率要好。读写锁的读锁的实现主要依赖于AQS的共享模式，而写锁依赖于独占模式。 简要说明 读写锁的实现，主要依赖于ReentrantReadWriteLock中的内部类： Sync类是读写锁同步控制...
深入理解ReentrantReadWriteLock：Java并发包的读写锁剖析
Sync类有两个内部类，HoldCounter和ThreadLocalHoldCounter，HoldCounter主要用于跟踪读锁的持有情况，ThreadLocalHoldCounter则可能是为了更好地管理线程级别的锁状态。 Sync类中的关键方法如acquireShared和...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值