作者简介:大家好,我是smart哥,前中兴通讯、美团架构师,现某互联网公司CTO
联系qq:184480602,加我进群,大家一起学习,一起进步,一起对抗互联网寒冬
学习必须往深处挖,挖的越深,基础越扎实!
阶段1、深入多线程
阶段2、深入多线程设计模式
阶段3、深入juc源码解析
码哥源码部分
码哥讲源码-原理源码篇【2024年最新大厂关于线程池使用的场景题】
码哥讲源码-原理源码篇【揭秘join方法的唤醒本质上决定于jvm的底层析构函数】
码哥源码-原理源码篇【Doug Lea为什么要将成员变量赋值给局部变量后再操作?】
码哥讲源码【谁再说Spring不支持多线程事务,你给我抽他!】
打脸系列【020-3小时讲解MESI协议和volatile之间的关系,那些将x86下的验证结果当作最终结果的水货们请闭嘴】
一、本章概述
本章将继续以ReentrantLock的调用为例,说明AbstractQueuedSynchronizer提供的Conditon等待功能。关于Conditon接口的介绍,可以参见:Java多线程进阶(二)—— juc-locks锁框架:接口。
二、Condition接口的实现
J.U.C包提供了Conditon接口,用以对原生的Object.wait()
、Object.notify()
进行增强。
Condition接口的实现类其实是在AQS中——ConditionObject
,ReentrantLock的newConditon方法其实是创建了一个AbstractQueuedSynchronizer.ConditionObject
对象:
ConditionObject作为AQS的内部类,复用了AQS的结点Node
,维护一个条件队列,队列初始时的结构如下:
示例
假设现在有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的源码,通过使用示例,加入调试断点一步步看内部的调用流程,主干理顺了之后,再看其它分支,其实是异曲同工的。