Java多线程进阶（7）—— J.U.C之locks框架：AQS的Conditon等待(3)

作者简介：大家好，我是smart哥，前中兴通讯、美团架构师，现某互联网公司CTO

联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬

学习必须往深处挖，挖的越深，基础越扎实！

阶段1、深入多线程

阶段2、深入多线程设计模式

阶段3、深入juc源码解析

阶段4、深入jdk其余源码解析

阶段5、深入jvm源码解析

码哥源码部分

码哥讲源码-原理源码篇【2024年最新大厂关于线程池使用的场景题】

码哥讲源码【炸雷啦！炸雷啦！黄光头他终于跑路啦！】

码哥讲源码-【jvm课程前置知识及c/c++调试环境搭建】

​​​​​​码哥讲源码-原理源码篇【揭秘join方法的唤醒本质上决定于jvm的底层析构函数】

码哥源码-原理源码篇【Doug Lea为什么要将成员变量赋值给局部变量后再操作？】

码哥讲源码【你水不是你的错,但是你胡说八道就是你不对了！】

码哥讲源码【谁再说Spring不支持多线程事务，你给我抽他！】

终结B站没人能讲清楚红黑树的历史，不服等你来踢馆！

打脸系列【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的源码，通过使用示例，加入调试断点一步步看内部的调用流程，主干理顺了之后，再看其它分支，其实是异曲同工的。