ReentrantReadWriteLock源码分析

概述

ReentrantReadWriteLock维护了一对相关的锁,它们分别是共享readLock和独占writeLock。关于共享读锁和排他写锁的概念其实很好理解。所谓共享读锁就是一个线程读的时候,其它线程也可以来读(共享),但是不能来写。排他写锁是指一个线程在写的时候,其它线程不能来写或读(排他)。除了这个特点之外,ReentrantReadWriteLock还有一个特点就是可重入的。它和ReentrantLock一样都是支持Condition的。而且ReentrantReadWerite还支持锁降级,即允许将写锁降级为读锁。

简单使用

最最基础的用法如下:

    ReentrantReadWriteLock lock=new ReentrantReadWriteLock();

    public void read(){
        lock.readLock().lock();
        //需要加读锁的操作
        lock.readLock().unlock();
    }

    public void write(){
        lock.writeLock().lock();
        //需要加写锁的操作
        lock.writeLock().unlock();
    }

ReentrantReadWriteLock无非就是这几种情况,读读共享,写写互斥,读写互斥,写读互斥。

下面我们就以这个最基础的用法,来分析一下其内部的原理

源码分析

继承体系

共享读锁的实现原理分析

lock方法

  1. 首先进入调用具体的实现
        public void lock() {
            sync.acquireShared(1);
        }
  1. 然后调用了这个方法
    public final void acquireShared(int arg) {
        if (tryAcquireShared(arg) < 0)
            doAcquireShared(arg);
    }

其中int tryAcquireShared(int unused)的具体实现如下:

 protected final int tryAcquireShared(int unused) {
            /*
             * Walkthrough:
             * 1. If write lock held by another thread, fail.
             * 2. Otherwise, this thread is eligible for
             *    lock wrt state, so ask if it should block
             *    because of queue policy. If not, try
             *    to grant by CASing state and updating count.
             *    Note that step does not check for reentrant
             *    acquires, which is postponed to full version
             *    to avoid having to check hold count in
             *    the more typical non-reentrant case.
             * 3. If step 2 fails either because thread
             *    apparently not eligible or CAS fails or count
             *    saturated, chain to version with full retry loop.
             */
            Thread current = Thread.currentThread();
            int c = getState();
            //持有写锁的线程可以获取读锁,如果获取锁的线程不是当前线程,则返回-1
            if (exclusiveCount(c) != 0 &&
                getExclusiveOwnerThread() != current)
                return -1;
            int r = sharedCount(c);//获取共享读锁的数量
            if (!readerShouldBlock() &&
                r < MAX_COUNT &&
                compareAndSetState(c, c + SHARED_UNIT)) {
                if (r == 0) {
                //如果首次获取锁,则初始化firstReader和firstReaderHoldCount
                    firstReader = current;
                    firstReaderHoldCount = 1;
                } else if (firstReader == current) {
                //如果当前线程是首次获取读锁的线程
                    firstReaderHoldCount++;
                } else {
                //更新HoldCounter
                    HoldCounter rh = cachedHoldCounter;
                    if (rh == null || rh.tid != getThreadId(current))
                        cachedHoldCounter = rh = readHolds.get();
                    else if (rh.count == 0)
                        readHolds.set(rh);
                    rh.count++;
                }
                return 1;
            }
            return fullTryAcquireShared(current);
        }

整个函数的工作流程如下:

  • 如果写锁已经被持有了,但是持有写锁的不是当前写出,那么就直接返回-1(体现写锁的排他性).
  • 如果在尝试获取锁是不需要阻塞等待(由锁的公平性决定),并且读锁的共享计数小于最大值,那么就直接通过CAS更新读锁数量,获取读锁。
  • 如果第二步执行失败了,那么就会调用fullTryAcquireShared(current)

fullTryAcquireShared(current)的具体实现如下:

 final int fullTryAcquireShared(Thread current) {
            /*
             * This code is in part redundant with that in
             * tryAcquireShared but is simpler overall by not
             * complicating tryAcquireShared with interactions between
             * retries and lazily reading hold counts.
             */
            HoldCounter rh = null;
            for (;;) { //自旋
                int c = getState();
                if (exclusiveCount(c) != 0) { //写锁已经被持有了
                    if (getExclusiveOwnerThread() != current) //持有写锁的不是单线程
                        return -1; //其它线程持有读锁后,就不能在获取写锁了
                    // else we hold the exclusive lock; blocking here
                    // would cause deadlock.
                } else if (readerShouldBlock()) {//由公平性决定需要阻塞
                    // Make sure we're not acquiring read lock reentrantly
                    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)
                                //如果当前线程的持有读锁数为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)) { //CAS更新读锁数量
                    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;
                }
            }
        }

可以看出其实int fullTryAcquireShared(Thread current)也每什么特别,它的代码和int tryAcquireShared(int unused)差不多。只不过是增加了自旋重试,和“持有读锁数的延迟读取”

  1. 我们回到void acquireShared(int arg)方法,如果tryAcquireShared(arg)获取读锁失败后,它调用的doAcquireShared(arg)又做了什么呢?
    它的具体实现如下:
 private void doAcquireShared(int arg) {
        final Node node = addWaiter(Node.SHARED); //添加一个共享模式的Node到等待队列尾部
        boolean failed = true;
        try {
            boolean interrupted = false; //获取前驱节点
            for (;;) {
                final Node p = node.predecessor();
                if (p == head) {
                //如果前驱节点,尝试获取资源
                    int r = tryAcquireShared(arg);
                    if (r >= 0) {
                    //获取成功,更新等待队列,并唤醒下一个等待的节点
                        setHeadAndPropagate(node, r);
                        p.next = null; // help GC
                        if (interrupted)
                            selfInterrupt();
                        failed = false;
                        return;
                    }
                }
                if (shouldParkAfterFailedAcquire(p, node) && //检查获取失败后是否可以阻塞
                    parkAndCheckInterrupt())
                    interrupted = true;
            }
        } finally {
            if (failed)
                cancelAcquire(node);
        }
    }

其实整个获取共享读锁的源码看下来,我们可以发现,AQS框架下,获取锁一般的流程就是首先尝试去直接获取,如果获取不到了,那么尝试自旋获取,如果还是获取不到,那么就去等待队列排队,排队的时候,如果发现自己是第二个那么就再次尝试获取锁,如果还是没获取到,那么就老老实实的在等待队列中park阻塞等待了。

我们通过源码,也可发现AQS框架下的锁,其实如果线程之间对锁的争用很低的时候,大多数时候直接就能拿到锁,几乎不需要排队,阻塞之类的,性能非常之高。

unlock方法

  1. 第一步还是调用具体的实现
        public void unlock() {
            sync.releaseShared(1);
        }
  1. 具体的实现如下
    public final boolean releaseShared(int arg) {
        if (tryReleaseShared(arg)) {
            doReleaseShared();
            return true;
        }
        return false;
    }
  1. 首先来看tryReleaseShared(arg)
  protected final boolean tryReleaseShared(int unused) {
            Thread current = Thread.currentThread();
            if (firstReader == current) { //如过当前线程是第一获取到读锁的线程
                // assert firstReaderHoldCount > 0;
                //直接更新线程持有数
                if (firstReaderHoldCount == 1)
                    firstReader = null;
                else
                    firstReaderHoldCount--;
            } 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;
                if (compareAndSetState(c, nextc)) //更新state
                    // Releasing the read lock has no effect on readers,
                    // but it may allow waiting writers to proceed if
                    // both read and write locks are now free.
                    return nextc == 0;
            }
        }

我们从tryReleaseShared(arg)的实现中可以看出,它的主要是去更新锁计数器和state。如果state为0的话,就返回true,否则就返回false。

  1. 我们回过头看,如果tryReleaseShared(arg)返回true,即锁释放后state为0了,那么它会执行doReleaseShared();方法,它的具体实现如下:
 private void doReleaseShared() {
        /*
         * Ensure that a release propagates, even if there are other
         * in-progress acquires/releases.  This proceeds in the usual
         * way of trying to unparkSuccessor of head if it needs
         * signal. But if it does not, status is set to PROPAGATE to
         * ensure that upon release, propagation continues.
         * Additionally, we must loop in case a new node is added
         * while we are doing this. Also, unlike other uses of
         * unparkSuccessor, we need to know if CAS to reset status
         * fails, if so rechecking.
         */
        for (;;) {
            Node h = head;
            if (h != null && h != tail) {
                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;
        }
    }

这个方法的作用就是唤醒等待队列中线程,现在资源已经空闲了,等待的线程可以唤醒来获取锁了。

排他写锁的实现原理分析

排他写锁的实现原理其实和ReentrantLock一致。我们只看几处和共享读锁不同的地方。

//公平锁实现
protected final boolean tryAcquire(int acquires) {
            final Thread current = Thread.currentThread();
            int c = getState();
            if (c == 0) {
                if (!hasQueuedPredecessors() && //判断当前线程是否还有前节点
                    compareAndSetState(0, acquires)) {//CAS修改state
                    //获取锁成功,设置锁的持有线程为当前线程
                    setExclusiveOwnerThread(current);
                    return true;
                }
            }
            else if (current == getExclusiveOwnerThread()) {//该线程之前已经拿到锁
                int nextc = c + acquires; //重入的体现
                if (nextc < 0)
                    throw new Error("Maximum lock count exceeded");
                setState(nextc); //更新State
                return true;
            }
            return false;
        }

其实非公平锁的实现也差不多,只不过少了!hasQueuedPredecessors()它不会去判断当前线程是否还有前驱节点,直接就开始获取锁了。

unlock方法也差不多我就不赘述了。

原文地址:https://www.cnblogs.com/zofun/p/12206876.html

时间: 2024-10-27 10:17:56

ReentrantReadWriteLock源码分析的相关文章

Java显式锁学习总结之五:ReentrantReadWriteLock源码分析

概述 我们在介绍AbstractQueuedSynchronizer的时候介绍过,AQS支持独占式同步状态获取/释放.共享式同步状态获取/释放两种模式,对应的典型应用分别是ReentrantLock和Semaphore,AQS还可以混合两种模式使用,读写锁ReentrantReadWriteLock就是如此. 设想以下情景:我们在系统中有一个多线程访问的缓存,多个线程都可以对缓存进行读或写操作,但是读操作远远多于写操作,要求写操作要线程安全,且写操作执行完成要求对当前的所有读操作马上可见. 分析

ReentrantReadWriteLock源码分析(一)

此处源码分析,主要是基于读锁,非公平机制,JDK1.8. 问题: 1.ReentrantReadWriteLock是如何创建读锁与写锁? 2.读锁与写锁的区别是什么? 3.锁的重入次数与获取锁的线程数分别是用哪种方式记录的? 4.当队列中出现多个共享模式的线程节点连续排列时,那么当第一个共享模式的线程拿到锁之后,后面的共享线程节点怎么获取锁? 一.创建ReadLock. ReentrantReadWriteLock rrw = new ReentrantReadWriteLock(); publ

多线程之美7一ReentrantReadWriteLock源码分析

目录 前言 在多线程环境下,为了保证线程安全, 我们通常会对共享资源加锁操作,我们常用Synchronized关键字或者ReentrantLock 来实现,这两者加锁方式都是排他锁,即同一时刻最多允许一个线程操作,然而大多数场景中对共享资源读多于写,那么存在线程安全问题的是写操作(修改,添加,删除),我们是否应该考虑将读和写两个分开,只要运用合理,并发性能是不是可以提高,吞吐量增大呢? ReentrantReadWriteLock已经为我们实现了这种机制,我们一起来看它是怎样实现的吧! 1.读写

java并发锁ReentrantReadWriteLock读写锁源码分析

1.ReentrantReadWriterLock基础 所谓读写锁,是对访问资源共享锁和排斥锁,一般的重入性语义为 如果对资源加了写锁,其他线程无法再获得写锁与读锁,但是持有写锁的线程,可以对资源加读锁(锁降级):如果一个线程对资源加了读锁,其他线程可以继续加读锁. java.util.concurrent.locks中关于多写锁的接口:ReadWriteLock public interface ReadWriteLock { /** * Returns the lock used for r

[源码分析]读写锁ReentrantReadWriteLock

一.简介 读写锁. 读锁之间是共享的. 写锁是独占的. 首先声明一点: 我在分析源码的时候, 把jdk源码复制出来进行中文的注释, 有时还进行编译调试什么的, 为了避免和jdk原生的类混淆, 我在类前面加了"My". 比如把ReentrantLock改名为了MyReentrantLock, 在源码分析的章节里, 我基本不会对源码进行修改, 所以请忽视这个"My"即可. 1. ReentrantReadWriteLock类里的字段 unsafe在这里是用来给TID_O

supervisor启动worker源码分析-worker.clj

supervisor通过调用sync-processes函数来启动worker,关于sync-processes函数的详细分析请参见"storm启动supervisor源码分析-supervisor.clj".sync-processes函数代码片段如下: sync-processes函数代码片段 ;; sync-processes函数用于管理workers, 比如处理不正常的worker或dead worker, 并创建新的workers;; supervisor标识supervis

深入理解读写锁—ReadWriteLock源码分析

ReadWriteLock管理一组锁,一个是只读的锁,一个是写锁.读锁可以在没有写锁的时候被多个线程同时持有,写锁是独占的. 所有读写锁的实现必须确保写操作对读操作的内存影响.换句话说,一个获得了读锁的线程必须能看到前一个释放的写锁所更新的内容. 读写锁比互斥锁允许对于共享数据更大程度的并发.每次只能有一个写线程,但是同时可以有多个线程并发地读数据.ReadWriteLock适用于读多写少的并发情况. Java并发包中ReadWriteLock是一个接口,主要有两个方法,如下: public i

jdk源码分析总览

今天看到了一个源码分析按照重要性排序的例子, 这里拿过来用了,之后按照这个顺序不断的完善源码的内容. 引用的出处忘记了(对作者说声抱歉) 很多java开发的小伙伴都会阅读jdk源码,然而确不知道应该从哪读起.以下为小编整理的通常所需阅读的源码范围. 标题为包名,后面序号为优先级1-4,优先级递减 1.java.lang 1) Object 12) String 13) AbstractStringBuilder 14) StringBuffer 15) StringBuilder 16) Boo

死磕 java同步系列之ReentrantReadWriteLock源码解析

问题 (1)读写锁是什么? (2)读写锁具有哪些特性? (3)ReentrantReadWriteLock是怎么实现读写锁的? (4)如何使用ReentrantReadWriteLock实现高效安全的TreeMap? 简介 读写锁是一种特殊的锁,它把对共享资源的访问分为读访问和写访问,多个线程可以同时对共享资源进行读访问,但是同一时间只能有一个线程对共享资源进行写访问,使用读写锁可以极大地提高并发量. 特性 读写锁具有以下特性: 是否互斥 读 写 读 否 是 写 是 是 可以看到,读写锁除了读读