ReentrantReadWriteLock 源码学习

最新推荐文章于 2024-05-14 18:14:06 发布
最新推荐文章于 2024-05-14 18:14:06 发布
阅读量131 收藏
点赞数
分类专栏： 锁 文章标签： lock
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/wsdfym/article/details/111173252
版权

文章目录

是什么

读写锁在同一时刻可以允许多个读线程访问，但是写线程操作时，所有的读线程和其他写线程均被阻塞。

使用例子

public class LockTest {
    private static ReadWriteLock lock = new ReentrantReadWriteLock();
     /**
     * 读取资源
     */
    public void read() throws InterruptedException {
        lock.readLock().lock();
        try{
           readSomething();
        }finally {
            lock.readLock().unlock();
        }
    }
    /**
     * 修改资源
     */
    public void write() throws InterruptedException {
        lock.writeLock().lock();
        try{
            writeSomething();
        }finally {
            lock.writeLock().unlock();
        }
    }
}

对比于排他锁

排他锁在同一时刻只允许一个线程进行访问，而读写锁在同一时刻可以允许多个读线程访问，但是在写线程访问时，其他线程会被阻塞，对于读多写少的场景并发性高。

其他方案（等待/通知）

等待/通知。在Java 5之前没有读写锁时候，当写操作开始时，所有晚于写操作的读操作均会进入等待状态，写操作完成并进行通知之后，所有等待的读操作才能继续执行。写操作需要通过synchronized进行同步。

继承结构

继承了ReadWriteLock接口，接口中只有两个方法
在这里插入图片描述

接口结构

在这里插入图片描述

  • Lock readLock();

返回用于读取的锁。

  • Lock writeLock();

返回用于写入的锁。

内部结构

按照惯例，先看一下内部结构，大概有个意识。
内部聚合了WriteLock，ReadLock。又都聚合了Sync（继承AQS）。
其中又有FairSync，NonfairSync 公平锁与非公平锁，都继承与Sync。
内部持有两把锁（读锁与写锁），并且根据Sync来实现功能，其中又分为公平锁方式与非公平锁方式。
在这里插入图片描述

/** 提供读锁的内部类 */
private final ReentrantReadWriteLock.ReadLock readerLock;
/** 提供写锁的内部类 */
private final ReentrantReadWriteLock.WriteLock writerLock;
/** 执行所有同步机制 */
final Sync sync;

Sync

获取写锁（独占锁）

AQS中被volatile修饰的代表锁状态的变量，在读写锁中被拆成了两半，高16位代表读锁的获取情况，低16位代表写锁的获取情况
在这里插入图片描述
1.获取写锁的状态
2.如果锁被其他线程获取，那么返回false
3.锁没有被获取，询问是否需要阻塞，如果需要阻塞，返回false，入队寻找时机休眠
4.不需要阻塞则尝试CAS获取锁

protected final boolean tryAcquire(int acquires) {
    
    Thread current = Thread.currentThread();
    int c = getState();
    //获取写锁的状态（同步状态值的低16位）
    int w = exclusiveCount(c);

    //1.锁被获取的情况（可能读锁，也能写锁）
    if (c != 0) {
        //如果写锁的状态为0，那么直接返回false
        if (w == 0
            //判断一下持有锁的线程，是否是当前线程,(需要考虑锁的重入)
            || current != getExclusiveOwnerThread())
            return false;
        //重入次数过多，抛出异常，（因为状态state只有一半表示写锁的状态）
        if (w + exclusiveCount(acquires) > MAX_COUNT)
            throw new Error("Maximum lock count exceeded");
        //锁重入
        setState(c + acquires);
        return true;
    }

    //2.锁没有被获取，询问是否需要阻塞（公平锁还是非公平锁处理方式不一致，也就是在这里体现出公平与非公平锁）。
    //writerShouldBlock公平锁与非公平锁的判断情况不一致。后续分析具体差别
    if (writerShouldBlock() ||
        //假设writerShouldBlock返回false，不需要阻塞。就会去尝试CAS修改同步状态。这里的c必定是0,acquires是1
        //CAS成功说明没有线程竞争，那么代表锁的状态c的值，从0->1,成功获取到锁
        !compareAndSetState(c, c + acquires))
        //线程需要进入同步队列，或者CAS失败，需要返回false，让线程进入同步队列（AQS模板方法）
        return false;
    
    //3.成功获取到锁,设置持有锁的线程为当前线程
    setExclusiveOwnerThread(current);
    return true;
}

**获取写锁的状态（同步状态值的低16位）**在读写锁中，将同步状态值一分为二，高十六位为读的状态，低16位为写锁的状态。

static int exclusiveCount(int c) { 
    return c & EXCLUSIVE_MASK; 
}

static final int EXCLUSIVE_MASK = (1 << 16) - 1;
1左移动16位，再减1
1： 0000 0000 0000 0000 0000 0000 0000 0001 1
左移29位： 0000 0000 0000 0001 0000 0000 0000 0000
减1： 0000 0000 0000 0000 1111 1111 1111 1111
任何数&EXCLUSIVE_MASK，舍弃高16位，保留低16位，得到写锁被线程获取的状态

是否需要进入同步队列的判断（公平锁/非公平锁的体现）

队头节点等于当前线程允许直接CAS
队头节点是当前线程需要进入AQS的同步队列

final boolean writerShouldBlock() {
    Node t = tail; 
    Node h = head;
    Node s;
    if(h != t){
        //false: 头节点后继不为null，并且后继节点等于当前线程（队头）
        //true: 头节点后继不为null或者后继节点不等于当前节点（不在队头）
        return (s = h.next) == null || s.thread != Thread.currentThread()
    } else {
        //队列都空了，允许直接CAS
        return false;
    }
}

非公平锁永远都允许先直接CAS，而不用入同步队列

final boolean writerShouldBlock() {
    return false;
}

不允许直接CAS，或者CAS失败进入同步队列等待

tryAcquire竞争锁失败了，线程构造成节点进入AQS的同步队列中。
后续情况在ReentrantLock中分析过了，不再赘述

public final void acquire(long arg) {
    if (!tryAcquire(arg) &&
        acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
        selfInterrupt();
}

释放写锁

1.将同步状态值减1
2.返回锁是否全部释放完毕

protected final boolean tryRelease(int releases) {
    //只有持有锁的线程才能释放锁，否则抛出错误
    if (!isHeldExclusively())
        throw new IllegalMonitorStateException();
    //状态减一
    int nextc = getState() - releases;
    //判断锁是否全部释放完毕（可重入锁可以多次获取锁）
    //低16位表示写锁的状态
    boolean free = exclusiveCount(nextc) == 0;
    if (free)
        //清除锁的被持有线程
        setExclusiveOwnerThread(null);
    setState(nextc);
    //只有全部释放完才会返回true
    return free;
}

获取读锁（共享锁）

tryAcquireShared在AQS也是未实现的方法，留给子类去实现。典型的模板设计模式

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

1.如果写锁被其他线程获取，直接返回-1，乖乖排队去。
2.判断是否需要阻塞，如果需要阻塞直接进入到fullTryAcquireShared方法，这个方法后面再看有对阻塞做出处理
3.不需要阻塞就一直尝试CAS，CAS成功做一些记录工作。失败进入入fullTryAcquireShared方法

protected final int tryAcquireShared(int unused) {
    Thread current = Thread.currentThread();
    int c = getState();
    //1.写锁被其他线程获取了，直接返回-1,未获得锁
    if (exclusiveCount(c) != 0 &&
        //并且保证线程的拥有者不是自身，后续会讲解到锁降级的情况，要考虑到
        getExclusiveOwnerThread() != current)
        return -1;
    //2.运行到这儿说明没有线程获取写锁,或者拥有锁的人是自身
    //获取读锁的数量
    int r = sharedCount(c);
    
    //（公平锁还是非公平锁处理方式不一致，也就是在这里体现出公平与非公平锁)，假设false执行CAS
    if (!readerShouldBlock() &&
        //获取读锁的线程数量是否超过最大值
        r < MAX_COUNT &&
        //CAS设置同步状态值，+ SHARED_UNIT是因为高16位才表示读锁的个数
        compareAndSetState(c, c + SHARED_UNIT)) {
        //设置同步状态值成功，做一些记录工作（暂时不用去看）
        if (r == 0) {
            // firstReader是把读锁状态从0变成1的那个线程（第一个获取读锁的线程）
            firstReader = current;
            firstReaderHoldCount = 1;
        //当前线程是第一次获取读锁的线程重入时，直接使用firstReaderHoldCount进行++
        } else if (firstReader == current) {
            firstReaderHoldCount++;
        } else { //从ThreadLocal中获取当前线程重入读锁的次数，然后自增下。
            //缓存的上一个线程的HoldCounter
            HoldCounter rh = cachedHoldCounter;
            if (rh == null || rh.tid != getThreadId(current))
                //不是同一个线程，从线程的ThreadLocal中取
                cachedHoldCounter = rh = readHolds.get();
            else if (rh.count == 0)
                //同一个线程，将缓存中的HoldCounter设置到线程的ThreadLocal
                readHolds.set(rh);
            //获取到读锁+1（rh是保存在各自线程中的一份副本，其他线程不可访问，只有自身线程可以访问）
            //这个else中做的东西其实就是讲各自线程获取锁的次数记录到ThreadLocal中
            rh.count++;
        }
        //竞争到读锁，返回true，不需要进入AQS的同步队列
        return 1;
    }
    //3.补偿循环尝试
    return fullTryAcquireShared(current);
}

公平锁获取读锁

与获取写锁一致

final boolean readerShouldBlock() {
    Node t = tail; 
    Node h = head;
    Node s;
    if(h != t){
        //false: 头节点后继不为null，并且后继节点等于当前线程（队头）
        //true: 头节点后继不为null或者后继节点不等于当前节点（不在队头）
        return (s = h.next) == null || s.thread != Thread.currentThread()
    } else {
        //队列都空了，允许直接CAS
        return false;
    }
}

非公平锁获取读锁

如果同步队列队头节点为写线程的话，那么就需要进入同步队列。
为了避免写线程无限期地饿死
试想一下，写线程在同步队列中等待，被持有的是读锁，持续的有读线程都可以获取读锁，那么写线程将很难获得写多，最终造成饥饿

final boolean readerShouldBlock() {
    Node h, s;
    //true:需要入同步队列，头队列非空，队头节点为写节点
    //false:不需要入同步队列  队列为空，或者队头节点为读节点
    return 
        //头结点不等于null
        (h = head) != null &&
        //后继节点不为null
        (s = h.next)  != null &&
        //后继节点不是读节点
        !s.isShared() &&
        //后继节点线程不为空
        s.thread != null;
}

fullTryAcquireShared

在什么情况下会进入到fullTryAcquireShared

  1. 目前没有线程获取写锁（有的话直接进入同步队列排队了）
  2. 或者CAS失败了。其上情况并不能确定线程一定没有拥有获取锁的资格。（有可能是重入锁的情况或者有其他读线程在竞争CAS）
    fullTryAcquireShared作为一个补偿方法
    方法中代码中对需要阻塞的情况做了处理如果是CAS失败，则会通过循环进行CAS的尝试。
final int fullTryAcquireShared(Thread current) {
   
    HoldCounter rh = null;
    for (;;) {
        int c = getState();
         //写锁被其他线程获取了，直接返回-1，表示失败（代码一致）
        if (exclusiveCount(c) != 0) {
            if (getExclusiveOwnerThread() != current)
                return -1;
                
        //对于需要进入同步队列的处理（公平锁非公平锁处理不一致）
        } else if (readerShouldBlock()) {
            // 如果这个线程是第一个获取读锁的线程，线程一定属于重入，直接放行进入循环CAS
            //与上述代码一致，不再赘述
            if (firstReader == current) {
                
            } else {
                if (rh == null) {
                    rh = cachedHoldCounter;
                    //先看本地缓存是否为Null，或者与当前线程id不一致
                    //进行一个ThreadLocal初始化
                    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");
            
        //运行到这一步说明不需要进入AQS的同步队列，或者是进行锁的重入
        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;
        }
    }
}

读锁的获取相对会比较麻烦

  1. 先判断是否有线程获得写锁，如果有那么直接进入同步队列，寻找休眠的机会线程休眠
  2. 如果写锁没有被获取，根据锁的类型判断线程是否应该被阻塞
  3. 如果不需要阻塞的话，则自旋CAS设置读锁的状态，并且将线程获取读锁的情况记录在ThreadLocal中

释放读锁（共享锁）

protected final boolean tryReleaseShared(int unused) {
    Thread current = Thread.currentThread();
    //第一个获取读锁的线程
    if (firstReader == current) {
        if (firstReaderHoldCount == 1)
            firstReader = null;
        else
            firstReaderHoldCount--;
    } else {
        //将线程中存在ThreadLocal减一处理
        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;
    }
    //循环CAS修改同步值状态
    for (;;) {
        int c = getState();
        //高16位代表读锁的状态
        int nextc = c - SHARED_UNIT;
        if (compareAndSetState(c, nextc))
            //==0也没有线程获取写锁
            return nextc == 0;
    }
}

结构

在这里插入图片描述

  • static final class HoldCounter

用来记录线程已经获取了多少次读锁的内部类

  • static final class ThreadLocalHoldCounter extends ThreadLocal<HoldCounter>

ThreadLocal，并且泛型指定位HoldCounter，初始化值为0。

以上两个内部类，用来实现读锁的可重入功能，如果值为0那么说明线程在之前没有获取读锁，反之线程已经是获取了读锁的并且没有释放。

核心属性

  • private transient ThreadLocalHoldCounter readHolds;

ThreadLocal。当前线程持有的重入读锁数目。每重入一次就会++。每释放一次–，当线程的hold count 变为0时被移除。

  • private transient HoldCounter cachedHoldCounter;

相对于当前最后一个获取读锁的线程

  • private transient Thread firstReader = null;
    private transient int firstReaderHoldCount;

firstReader 是第一个获取了读锁的线程（没有释放锁）。firstReaderHoldCount 是 firstReader 的 hold count（即重入次数）

WriteLock 写锁

方法代理到Sync获取独占锁，释放独占锁。按照AQS的模板方法，如果获取锁失败，那么进入同步队列，等待唤醒。
AQS释放锁，唤醒同步队列中的后继线程。

  1. lock() 加锁
public void lock() {
    sync.acquire(1);
}
public final void acquire(int arg) {
    if (!tryAcquire(arg) &&
        acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
        selfInterrupt();
}
  1. unlock() 释放锁
public void unlock() {
    sync.release(1);
}
//AQS释放锁
public final boolean release(int arg) {
    if (tryRelease(arg)) {
        Node h = head;
        if (h != null && h.waitStatus != 0)
            unparkSuccessor(h);
        return true;
    }
    return false;
}

ReadLock 读锁

其行为都是代理到Sync的，获取共享锁，释放独占锁。

  1. lock() 加锁
public void lock() {
    sync.acquireShared(1);
}
public final void acquireShared(int arg) {
    if (tryAcquireShared(arg) < 0)
        doAcquireShared(arg);
}
//以共享的不间断模式进行获取
private void doAcquireShared(int arg) {
    final Node node = addWaiter(Node.SHARED);
    boolean failed = true;
    try {
        boolean interrupted = false;
        for (;;) {
            final Node p = node.predecessor();
            if (p == head) {
                //Sync实现的以为共享的方式获取锁
                int r = tryAcquireShared(arg);
                if (r >= 0) {
                    //设置队列的头部，并检查后继者是否为共享模式（读锁），是的话也进行唤醒
                    setHeadAndPropagate(node, r);
                    p.next = null; 
                    if (interrupted)
                        selfInterrupt();
                    failed = false;
                    return;
                }
            }
            if (shouldParkAfterFailedAcquire(p, node) &&
                parkAndCheckInterrupt())
                interrupted = true;
        }
    } finally {
        if (failed)
            cancelAcquire(node);
    }
}
  1. unlock() 释放锁
public void unlock() {
    sync.releaseShared(1);
}
public final boolean releaseShared(int arg) {
    if (tryReleaseShared(arg)) {
        //唤醒后继线程，检查后继者是否为共享模式（读锁），是的话也进行唤醒
        doReleaseShared();
        return true;
    }
    return false;
}

锁降级

锁降级指的是写锁降级成为读锁。锁降级是指把持住（当前拥有的）写锁，再获取到读锁，随后释放（先前拥有的）写锁的过程。

public void processData() {
    // 锁降级从写锁获取到开始
    writeLock.lock();
    try {
        write();
        readLock.lock();
    } finally {
        writeLock.unlock();
    }
    // 锁降级完成，写锁降级为读锁
    try {
        read();
    } finally {
            readLock.unlock();
    }
}

锁降级中读锁的获取是否必要呢？答案是必要的。主要是为了保证数据的可见性，如果当前线程不获取读锁而是直接释放写锁，假设此刻另一个线程（记作线程T）获取了写锁并修改了数据，那么当前线程无法感知线程T的数据更新。

吴顺达
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
juc源码视频教程最全
05-22
通过学习JUC源码，我们可以了解到这些组件如何在底层实现线程同步、锁机制和数据一致性，这对于提升并发编程能力，解决实际问题非常有帮助。"juc源码视频教程"将引导你逐层剖析这些组件的内部工作原理，让你在实践中...
Java 多线程学习总结6
03-13
在“Java多线程学习总结6”这个主题中，我们可以深入探讨Java多线程的实现、管理及优化。下面将详细阐述相关知识点。 1. **线程的创建方式** - **继承Thread类**：自定义类继承Thread类，并重写run()方法，创建...
ReentrantReadWriteLock读写锁
m0_56054652的博客
11-04 2005
一、前言 ReentrantReadWriteLock中包含三种锁：读写锁、可重入锁、公平/非公平锁 1、读写锁 2、可重入锁： 又名递归锁，是指在同一个线程在外层方法获取锁的时候，在进入内层方法会自动获取锁。说的有点抽象，下面会有一个代码的示例。 对于Java ReetrantLock而言，从名字就可以看出是一个重入锁，其名字是Re entrant Lock 重新进入锁。 对于Synchronized而言，也是一个可重入锁。可重入锁的一个好处是可一定程度避免死锁。 syn...
并发编程之ReentrantReadWriteLock详解
尽力而为！
01-13 1320
ReentrantReadWriteLock是Java中的一个读写锁实现，它允许多个线程同时读取共享资源（读读可以并发），但在写入时只允许一个线程独占（读写，写读，写写互斥）。这个锁支持重入，即同一个线程可以多次获取相同类型的锁。这种锁可以提高读操作的并发性，同时保证写操作的独占性。在读多于写的情况下，读写锁能够提供比排它锁更好的并发性和吞吐量。线程进入读锁的前提条件没有其他线程的写锁没有写请求或者有写请求，但调用线程和持有锁的线程是同一个。
2024年Android最新读写锁-ReentrantReadWriteLock源码分析与图解，2024年最新android 面试题目
最新发布
2401_84556656的博客
05-14 597
【Android 详细知识点思维脑图（技能树）】我个人是做Android开发，已经有十来年了，目前在某创业公司任职CTO兼系统架构师。虽然 Android 没有前几年火热了，已经过去了会四大组件就能找到高薪职位的时代了。这只能说明 Android 中级以下的岗位饱和了，现在高级工程师还是比较缺少的，很多高级职位给的薪资真的特别高（钱多也不一定能找到合适的），所以努力让自己成为高级工程师才是最重要的。这里附上上述的面试题相关的几十套字节跳动，京东，小米，腾讯、头条、阿里、美团等公司19年的面试题。
ReentrantReadWriteLock详解
weixin_41951205的博客
02-28 781
一、简介 1. 什么是读写锁 前面我们介绍了ReentrantLock类，知道它的功能类似synchronized关键字，属于排它锁，同一时刻仅有一个线程可以进行访问。但是在大部分的场景下，读操作往往远大于写操作，其中读操作之前不存在数竞争关系，而写操作与其余的读写操作互斥。因此JDK为我们提供了读写锁——ReentrantReadWriteLock。 读写锁维护着一对锁，一个读锁和一个写锁。通过分离读锁和写锁，使得并发性比一般的排他锁有了较大的提升：在同一时间可以允许多个读线程同时访问，但是在写线程访问时
【多线程】读写锁ReentrantReadWriteLock源码分析
weixin_44823875的博客
11-25 562
ReentrantLock完全可以解决线程安全问题，但是ReentrantLock是独占锁，某一时间只能有一个线程可以获取锁，其他线程只能等待。现实中有很多“写少读多”的场景，那么我们就希望同一时间只能有一个写线程可以获取写锁，但是同时可以多个读线程可以获取读锁，于是便有了ReentrantReadWriteLock。ReentrantReadWriteLock采用读写分离策略，允许多个线程可以同时获取读锁。
zkclient 1.0 源码包
12-04
**源码学习重点** 在深入研究 zkclient 的源码时，以下几个方面值得重点关注： 1. **ZkClient 类**: 这是 zkclient 的核心类，包含了连接管理、会话管理、事件监听等功能的实现。 2. **Watch事件处理**: 研究 ...
homework-ReadWriteLock-KristampsW-main.zip
04-17
通过对`ReadWriteLock`的源码学习，我们可以更好地理解和定制自己的并发控制策略，优化多线程环境下的程序性能。在阅读源码时，重点关注锁的获取、释放逻辑，以及AQS的使用，这将有助于我们深入理解Java并发编程的...
java并发编程电子书
03-24
《Java并发编程实践》这本书是Java开发者深入理解并发编程的重要...通过阅读《Java并发编程实践》，开发者可以学习到如何编写高效、稳定的并发程序，避免并发陷阱，提升软件质量。同时，书中实例丰富，便于实践和理解。
十、详解ReentrantReadWriteLock读写锁
2301_77203215的博客
12-28 886
之前我们讲过可重入锁从这篇博文中我们可以了解到，基于lock的锁底层都是利用aqs这个抽象类的。那么在读写锁中，其本质也是利用aqs，与可重入锁之间的区别的就是在实现抽象方法的时候，具体的逻辑不一样。可以理解为两者骨架一样，但是具体细节逻辑有区别，尤其是在tryAcquire和tryRelease的逻辑不一样。
读写锁ReentrantReadWriteLock的原理
andy的博客
01-09 981
解决线程安全问题使用ReentrantLock就可以，但是ReentrantLock是独占锁，某时只有一个线程可以获取该锁，而实际中会有写少读多的场景，显然ReentrantLock满足不了这个需求，所以ReentrantReadWriteLock应运而生。ReentrantReadWriteLock采用读写分离的策略，允许多个线程可以同时获取读锁。
全网最详细的ReentrantReadWriteLock源码解析
zhujiangtaotaise的专栏
06-22 1247
前言： 之前的文章讲了AQS 和 ReentrantLock 的实现，想看之前的文章可以点击Java高频面试之— AQS原理解析。 ReentrantReadWriteLock 的实现也是基于AQS实现的，代码也不是很复杂，下面开讲。 简介 之前讲到 AQS 有2个最重要的属性， state, 它是int型的，表示加锁的状态，初始状态值为0；另外 一个是 exclusiveOwnerThread，它表示的是获得锁的线程，也叫独占线程。AQS中还有一个用来存储获取锁失败线程的队列，以及head 和 tail
ReentrantReadWriteLock 源码
weixin_43248672的博客
10-06 188
读写锁主要使用在读多写少的场景中，读写锁允许同一时刻被多个读线程访问，但是在写线程访问时，所有的读线程和其他的写线程都会被阻塞。还是基于AQS实现的。很多功能的实现和类似，还是基于AQS的state来确定当前线程是否拿到锁资源。在中，将state的高16位作为读锁的标识，而将低16位作为写锁的标识。其中，读写锁有以下几种规则：读读操作是共享的。写写操作是互斥的。读写操作是互斥的。写读操作是互斥的。单个线程获取写锁后，再次获取读锁，可以拿到。（写读可重入）
ReentrantReadWriteLock读写锁的lock、unlock源码分析
qq_42949615的博客
05-06 599
先说一下结论，再分析源码，ReentrantReadWriteLock拆分了两把锁，一把读锁ReadLock，一把写锁WriteLock，读锁是共享的，写锁是独占的；也就是说，如果有线程在读，其他线程也可以读，但是不能写；如果有线程在写，则其他线程不能读也不能写。 lock ReadLock 一、tryAcquireShared 获取共享锁 先来看第一个方法tryAcquireShared获取共享锁 主要分四部分，介绍这四部分之前先来介绍一点东西，AQS里边只有一个state来记录锁的
ReentrantReadWriteLock之深入源码解析
weixin_53067547的博客
02-01 1483
ReentrantLock是排他锁，在高并发读多写少的场景下，同时还要保证线程安全，如果使用ReentrantLock的效率不是那么好，所以才有了ReentrantReadWriteLock。在讲源码之前，我们对读写锁要有个认知。读读操作是共享的。读写操作是互斥的。写写操作是互斥的。写读操作是互斥的。（写读两个不同线程）单线程获取写锁后，再次获取读锁，可以拿到。（写读操作可以重入）单线程获取读锁后，再次获取写锁，不可以拿到。
ReentrantReadWriteLock acquireShared源码分析
johnhuster的专栏
08-19 854
public final void acquireShared(int arg) { if (tryAcquireShared(arg) < 0) doAcquireShared(arg); } //该方法不会阻塞，该方法只是尝试获取而已，获取失败后就会调用doAcquireShared，...
reentrantreadwritelock源码
03-16
ReentrantReadWriteLock的源码实现比较复杂，主要包括两个内部类：Sync和FairSync。Sync是ReentrantReadWriteLock的核心实现，它维护了读锁和写锁的状态，以及等待队列。FairSync是Sync的子类，它实现了公平锁的逻辑...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值