详解AQS中的condition源码原理
2023-09-14 09:05:46 时间
摘要:condition用于显式的等待通知,等待过程可以挂起并释放锁,唤醒后重新拿到锁。
本文分享自华为云社区《AQS中的condition源码原理详细分析》,作者:breakDawn。
condition的用法
condition用于显式的等待通知,等待过程可以挂起并释放锁,唤醒后重新拿到锁。
和直接用lock\unlock去做等待通知的区别在于,lock是不会释放锁的,但是利用的condition的await则可以,且唤醒后会自动重新拿回锁。
Lock lock = new ReentrantLock();
Condition condition = lock.newCondition();
public void conditionWait() throws InterruptedException {
lock.lock();
try {
// if(xxxx)判断不满足条件,等待,释放锁
condition.await();
} finally {
lock.unlock();
}
}
public void conditionSignal() throws InterruptedException {
lock.lock();
try {
// 做完事情了,通知condition上等待的开始抢占
condition.signal();
} finally {
lock.unlock();
}
}
也提供了一些支持中断、支持超时的等待方法
condition 和 object.wait/notify的区别
- object的wait依赖sync, 只能最多有一个等待队列。 而通过newCondition可以制造多个等待队列
- wait不支持中断,而condition支持
- condition支持等待特定时间
condition原理分析
超大原理流程图
- await(), 简单来讲就是把当前线程放入condition的等待队列中,然后调用LockSupport.park拉起线程。如果被其他线程通过signal唤醒,则放入同步队列中竞争锁,竞争成功则返回,否则继续竞争。
- signal方法,就是拿到condition的等待队列头节点,用cas修改节点状态,改成功则唤醒线程。但有可能被别人抢先,所以需要cas操作。
代码结构部分:
Lock提供了newCondition接口给外部锁调用
而newCondition()返回的Condition是一个接口
这个接口的实现类是ConditionObject,放在AQS抽象类的内部类中
原理实现部分
等待队列
- 每个condition都有一个属于自己的等待队列
- 每次调用condition.await, 就插入到等待队列尾部
- 等待队列插入封装线程的节点时不需要在尾部CAS, 因为必须先获取锁,才能调用await,因此不用CAS竞争
- 每个Lock只有一个同步队列(用于lock()时阻塞和竞争用), 但是可能会有多个等待队列(用于condition的await)
等待过程
- 添加线程到condition的等待队列尾部
- 释放占用的锁,并唤醒同步队列的后继节点
- 此时肯定不在aqs的同步队列中了, 用park方法进入阻塞状态
- 被唤醒,唤醒时可能是通过sign()被人放入了同步队列, 也可能是被中断唤醒,因此要做checkInterruptWhileWaiting检查看是否继续, 如果同意继续,就继续睡眠,直到进入同步队列
- 尝试acquireQueued竞争和抢占state同步状态
- 退出前,顺带用unlinkCancelledWaiters清理已经不是CONDITION状态的等待队列节点
public final void await() throws InterruptedException {
if (Thread.interrupted())
throw new InterruptedException();
// 添加本线程到等待队列尾部
Node node = addConditionWaiter();
// 释放锁,唤醒同步队列中的后继节点
int savedState = fullyRelease(node);
int interruptMode = 0;
// 如果已经在同步队列中了,说明被成功sign唤醒
while (!isOnSyncQueue(node)) {
// 阻塞挂起
LockSupport.park(this);
// 确认是否需要中断时就退出
if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
break;
}
// 在同步队列中,那就按同步队列的规则在队列中用CAS竞争同步状态
if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
interruptMode = REINTERRUPT;
// 清理已经不是CONDITION状态的等待队列节点
if (node.nextWaiter != null)
unlinkCancelledWaiters();
if (interruptMode != 0)
reportInterruptAfterWait(interruptMode);
}
唤醒过程signal()
1.检查调用signal时,是否当前线程获取了锁,不是则抛异常
if (!isHeldExclusively())
throw new IllegalMonitorStateException();
2.获取condition队列中的第一个等待节点
Node first = firstWaiter;
if (first != null)
doSignal(first);
3.用CAS清除CONDITION状态
if (!node.compareAndSetWaitStatus(Node.CONDITION, 0))
return false;
4.调用AQS的enq(firstWaitNode),将这个节点放入到同步队列的队尾(需要CAS支撑?因为可能是共享的,即使获取了锁也需要竞争)
Node p = enq(node);
5.移动入同步队列成功后(可能经历了几次CAS),再用unpark方法唤醒,那个线程就进入了上面代码中Park之后的部分了
int ws = p.waitStatus;
if (ws > 0 || !p.compareAndSetWaitStatus(ws, Node.SIGNAL))
LockSupport.unpark(node.thread);
6.如果是signalAll方法,则等待队列中每个节点都执行一次signal方法,全部移入同步队列中并唤醒(唤醒后他们很可能还会因为抢不到资源而阻塞,但队列位置不同了,也无法再通过sign唤醒了)
do {
Node next = first.nextWaiter;
first.nextWaiter = null;
transferForSignal(first);
first = next;
} while (first != null);
相关文章
- Spring基础-10-源码分析
- 【nodejs原理&源码赏析(7)】【译】Node.js中的事件循环,定时器和process.nextTick
- 【nodejs原理&源码赏析(5)】net模块与通讯的实现
- jQuery源码分析系列(31) : Ajax deferred实现
- Spring Cloud Netflix Eureka源码导读与原理分析
- Spark修炼之道(高级篇)——Spark源码阅读:第六节 Task提交
- hbase源码系列(三)Client如何找到正确的Region Server
- PHP 源码探秘 - 线程安全的实现原理
- Reflux原理与源码详解
- 源码扫描的工作原理
- LNMP详解(二)——Nginx源码安装与启动
- 【Android笔记87】Android之两种开发模式介绍MVC和MVP(登录小案例源码)
- 深度理解Android InstantRun原理以及源码分析
- android8.0 Launcher的源码启动过程InvariantDeviceProfile获取硬件参数,确认布局参数
- ijkPlayer源码分析 PacketQueue分析
- 【nodejs原理&源码赏析(4)】深度剖析cluster模块源码与node.js多进程(上)
- 【nodejs原理&源码赏析(7)】【译】Node.js中的事件循环,定时器和process.nextTick
- 【nodejs原理&源码杂记(8)】Timer模块与基于二叉堆的定时器
- 【nodejs原理&源码赏析(1)】Express中间件系统的基本实现
- Apache工具包方法——Hex.encodeHexString(byte[] data)源码浅析
- spring源码阅读--@Transactional实现原理
- 怎样加入� android private libraries 中的包的源码
- 第二人生的源码分析(二十六)底层网络协议
- 第二人生的源码分析(四十七)发送下载纹理图片请求
- (01)ORB-SLAM2源码无死角解析-(40) EPnP 算法原理详解→理论基础四:QR分解(豪斯霍尔德Householder变换)
- (01)ORB-SLAM2源码无死角解析-(39) EPnP 算法原理详解→理论基础三:高斯牛顿迭代
- Etcd Kubernetes 集群稳定性:LIST 请求源码分析、性能评估与大规模基础服务部署调优
- AppArmor零知识学习九、源码构建(6)
- platform_get_resource=NULL内核源码分析
- (7)Blender源码分析之创建区域对象