资讯专栏INFORMATION COLUMN

Java多线程进阶(八)—— J.U.C之locks框架:AQS的Conditon等待(3)

ityouknow / 1668人阅读

摘要:关于接口的介绍,可以参见多线程进阶二锁框架接口。最终线程释放了锁,并进入阻塞状态。当线程被通知唤醒时,则是将条件队列中的结点转换成等待队列中的结点,之后的处理就和独占功能完全一样。

本文首发于一世流云的专栏:https://segmentfault.com/blog...
一、本章概述

本章将继续以ReentrantLock的调用为例,说明AbstractQueuedSynchronizer提供的Conditon等待功能。关于Conditon接口的介绍,可以参见:Java多线程进阶(二)—— juc-locks锁框架:接口。

二、Condition接口的实现

J.U.C包提供了Conditon接口,用以对原生的Object.wait()Object.notify()进行增强。

Condition接口的实现类其实是在AQS中——ConditionObject,ReentranLock的newConditon方法其实是创建了一个AbstractQueuedSynchronizer.ConditionObject对象:

Condition作为AQS的内部类,复用了AQS的结点,维护一个条件队列,队列初始时的结构如下:

示例
假设现在有3个线程:ThreadA、ThreadB、ThreadC,一个Conditon实现对象。
ReentrantLock lock = new ReentrantLock();
Conditon con = lock.newConditon();

线程将以以下的时序调用:

//ThreadA先调用lock方法获取到锁,然后调用con.await()

//ThreadB获取锁,调用con.signal()唤醒ThreadA

//ThreadB释放锁
1. ThreadA获取到锁后,首先调用await方法

上述方法,先对线程中断做一次预判断,然后将线程包装成结点插入【条件队列】,插入完成后,条件队列的结构如下:

我们知道,await()方法会释放当前线程持有的锁,这个过程其实就是fullyRelease方法的作用:

然后,判断当前结点是不是在【等待队列】中,不在的话就会阻塞线程。
最终线程A释放了锁,并进入阻塞状态。

2. ThreadB获取到锁后,首先调用signal方法

由于Condition的signal方法要求线程必须获得与此Condition对象相关联的锁,所以这里有个中断判断:

然后,会调用doSignal方法,删除条件队列中的队首CONDITION类型结点:

删除完成后,transferForSignal方法会将CONDITON结点转换为初始结点,并插入【等待队列】:

此时,【条件队列】已经空了:

而ThreadA被包装成新结点后,插入【等待队列】:

3. ThreadB释放锁

终于ThreadB释放了锁,释放成功后,会调用unparkSuccessor方法(参加AQS独占功能的讲解),唤醒队列中的首结点:

最终等待队列结构如下:

4. ThreadA从唤醒处继续执行

ThreadA被唤醒后,从await方法的阻塞处开始继续往下执行:

之后会调用acquireQueued方法再次尝试获取锁,获取成功后,最终等待队列状态如下:

三、总结

本章以ReentrantLock的公平锁为例,分析了AbstractQueuedSynchronizer的Condition功能。
通过分析,可以看到,当线程在指定Condition对象上等待的时候,其实就是将线程包装成结点,加入了条件队列,然后阻塞。当线程被通知唤醒时,则是将条件队列中的结点转换成等待队列中的结点,之后的处理就和独占功能完全一样。

除此之外,Condition还支持限时等待、非中断等待等功能,分析思路是一样的,读者可以自己去阅读AQS的源码,通过使用示例,加入调试断点一步步看内部的调用流程,主干理顺了之后,再看其它分支,其实是异曲同工的。

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/76553.html

相关文章

  • Java线程进阶(二)—— J.U.Clocks框架:接口

    摘要:二接口简介可以看做是类的方法的替代品,与配合使用。当线程执行对象的方法时,当前线程会立即释放锁,并进入对象的等待区,等待其它线程唤醒或中断。 showImg(https://segmentfault.com/img/remote/1460000016012601); 本文首发于一世流云的专栏:https://segmentfault.com/blog... 本系列文章中所说的juc-...

    dkzwm 评论0 收藏0
  • Java线程进阶(七)—— J.U.Clocks框架AQS独占功能剖析(2)

    摘要:开始获取锁终于轮到出场了,的调用过程和完全一样,同样拿不到锁,然后加入到等待队列队尾然后,在阻塞前需要把前驱结点的状态置为,以确保将来可以被唤醒至此,的执行也暂告一段落了安心得在等待队列中睡觉。 showImg(https://segmentfault.com/img/remote/1460000016012467); 本文首发于一世流云的专栏:https://segmentfault...

    JayChen 评论0 收藏0
  • Java线程进阶(九)—— J.U.Clocks框架AQS共享功能剖析(4)

    摘要:好了,继续向下执行,尝试获取锁失败后,会调用首先通过方法,将包装成共享结点,插入等待队列,插入完成后队列结构如下然后会进入自旋操作,先尝试获取一次锁,显然此时是获取失败的主线程还未调用,同步状态还是。 showImg(https://segmentfault.com/img/remote/1460000016012541); 本文首发于一世流云的专栏:https://segmentfa...

    CompileYouth 评论0 收藏0
  • Java线程进阶(十)—— J.U.Clocks框架:基于AQS读写锁(5)

    摘要:关于,最后有两点规律需要注意当的等待队列队首结点是共享结点,说明当前写锁被占用,当写锁释放时,会以传播的方式唤醒头结点之后紧邻的各个共享结点。当的等待队列队首结点是独占结点,说明当前读锁被使用,当读锁释放归零后,会唤醒队首的独占结点。 showImg(https://segmentfault.com/img/remote/1460000016012293); 本文首发于一世流云的专栏:...

    dunizb 评论0 收藏0
  • Java线程进阶(三)—— J.U.Clocks框架:ReentrantLock

    摘要:公平策略在多个线程争用锁的情况下,公平策略倾向于将访问权授予等待时间最长的线程。使用方式的典型调用方式如下二类原理的源码非常简单,它通过内部类实现了框架,接口的实现仅仅是对的的简单封装,参见原理多线程进阶七锁框架独占功能剖析 showImg(https://segmentfault.com/img/remote/1460000016012582); 本文首发于一世流云的专栏:https...

    jasperyang 评论0 收藏0

发表评论

0条评论

ityouknow

|高级讲师

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<