ReentrantReadWriteLock源码分析

以前分析过AQS的源码以及线程池和堵塞队列源码的时候,其实看过这个这个源码的,但是总是会忘,故分析一下,记录下来。

有了前面的基础,其实ReentrantReadWriteLock源码相对比较简单。

ReentrantReadWriteLock的使用,大概是,
reentrantReadWriteLock.readLock().lock();
reentrantReadWriteLock.writerLock().lock();
也就是,读锁和写锁,读读不互斥,写和任何锁互斥。

构造方法
可以看到维护了两把锁,一把读锁,一把写锁

public ReentrantReadWriteLock(boolean fair) {
       sync = fair ? new FairSync() : new NonfairSync();
       readerLock = new ReadLock(this);
       writerLock = new WriteLock(this);
   }

可以看到sync实现了AQS

abstract static class Sync extends AbstractQueuedSynchronizer {

看它的lock方法,调用的是sync的lock,如果是默认的构造方法,则调用的是非公平锁的lock方法。

 public void lock() {
        sync.lock();
    }

非公平锁的lock方法


 final void lock() {
// 直接争取锁资源,不管队列有没有元素
            if (compareAndSetState(0, 1))
                setExclusiveOwnerThread(Thread.currentThread());
            else
                acquire(1);
        }
final boolean nonfairTryAcquire(int acquires) {
            final Thread current = Thread.currentThread();
            int c = getState();
            if (c == 0) {
// 直接争取锁资源,不管队列有没有元素
                if (compareAndSetState(0, acquires)) {
                    setExclusiveOwnerThread(current);
                    return true;
                }
            }
// 如果state不为0,则说明这个线程已经获得锁了,这里只是再获取一次,则只是把state + 1,也就是加 acquires
            else if (current == getExclusiveOwnerThread()) {
                int nextc = c + acquires;
                if (nextc < 0) // overflow
                    throw new Error("Maximum lock count exceeded");
                setState(nextc);
                return true;
            }
            return false;
        }

公平锁的lock方法
对比非公平锁的lock方法,可以看到,非公平锁,会直接去cas争取state,也就是直接争取锁的资源,公平锁,则会去看队列中有没有元素,没有才,获取锁,有,则进入队列,也就是有公平顺序的。

final void lock() {
            acquire(1);
        }
protected final boolean tryAcquire(int acquires) {
            final Thread current = Thread.currentThread();
            int c = getState();
            if (c == 0) {
// 公平锁会看一下队列有没有元素,有,则按先后顺序,自己进入队列
                if (!hasQueuedPredecessors() &&
                    compareAndSetState(0, acquires)) {
                    setExclusiveOwnerThread(current);
                    return true;
                }
            }
            else if (current == getExclusiveOwnerThread()) {
                int nextc = c + acquires;
                if (nextc < 0)
                    throw new Error("Maximum lock count exceeded");
                setState(nextc);
                return true;
            }
            return false;
        }

释放锁:也就是释放资源,许可证-1,也就是lock了几次,就要unlock几次。

 public void unlock() {
        sync.release(1);
    }
 public final boolean release(int arg) {
        // 尝试释放资源
        if (tryRelease(arg)) {
          // 释放成功,则唤醒AQS的双向node链表的头部节点
            Node h = head;
            if (h != null && h.waitStatus != 0)
                unparkSuccessor(h);
            return true;
        }
        return false;
    }
  protected final boolean tryRelease(int releases) {
            int c = getState() - releases;
            if (Thread.currentThread() != getExclusiveOwnerThread())
                throw new IllegalMonitorStateException();
            boolean free = false;
            if (c == 0) {
                free = true;
                setExclusiveOwnerThread(null);
            }
            setState(c);
            return free;
        }

至于一些acquire方法的尝试获取锁和入队等AQS的操作,不再细讲,可以看之前的AQS源码分析。

还有一个常用的操作是:
Condition condition = reantrantLock.newCondition();
condition.await();
condtion.signal();
实现类似object的wait和signal的功能。
这个condition是一个接口,conditionObject是它的实现类,condition是AQS维护的内部类,关于它的原理,前面AQS的源码有分析,这里摘抄一下大概原理:

调用condition.await()方法,意味着当前线程进入等待状态。将当前节点包装成node节点,放入condition链表的尾部。然后调用AQS的release方法,释放state,locksupport.unpack()双向node链表的头结点线程。之后,再将自身线程堵塞。

signal方法总结:调用condition.signal()方法,意味着唤醒其他线程调用condition.await()方法进入等待状态的线程。会将conditionObject维护的node单向链表的头节点(也就是第一个调用condition.await的线程节点),移动到AQS维护的双向node节点的尾部,等待其他线程使用完资源后调用release方法一个一个唤醒。

 public Condition newCondition() {
        return sync.newCondition();
    }
 final ConditionObject newCondition() {
            return new ConditionObject();
        }

总结:公平锁和非公平锁,的区别就是,非公平锁不管AQS维护的双向链表队列有没有元素,直接cas获取state,获取资源许可证。而公平锁则会看队列是否元素,有则放到队列尾部,按顺序获取资源锁。

reentrantlock的lock一次,则AQs的state则+1,lock一次则加-,unlock一次,则减1,也就是lock了几次,就要unlock几次。

reentrantlock的new Condition方法,新建的就是AQS的conditionObject,await一下,则把线程node放入conditionobject维护的单向链表,signal一次,则把conditionObject维护的单链表的头部节点,转入AQS双向链表的尾部,等待一个一个获取锁资源。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 215,923评论 6 498
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,154评论 3 392
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 161,775评论 0 351
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,960评论 1 290
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,976评论 6 388
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,972评论 1 295
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,893评论 3 416
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,709评论 0 271
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,159评论 1 308
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,400评论 2 331
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,552评论 1 346
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,265评论 5 341
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,876评论 3 325
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,528评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,701评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,552评论 2 368
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,451评论 2 352

推荐阅读更多精彩内容