Lock框架中的Condition机制
还是看一下之前ReentrantLock中调用condition方法的流程图 👇
任何一个java对象都天然继承于Object类,在线程间实现通信的往往会应用到Object的几个方法,比如wait(),wait(long timeout),wait(long timeout, int nanos)与notify(),notifyAll()几个方法实现等待/通知机制,同样的, 在java Lock体系下依然会有同样的方法实现等待/通知机制。
从整体上来看Object的wait和notify/notify是与对象监视器配合完成线程间的等待/通知机制,而Condition与Lock配合完成等待通知机制,前者是java底层级别的,后者是语言级别的,具有更高的可控制性和扩展性。两者除了在使用方式上不同外,在功能特性上还是有很多的不同:
- Condition能够支持不响应中断,而通过使用Object方式不支持;
- Condition能够支持多个等待队列(new 多个Condition对象),而Object方式只能支持一个;
- Condition能够支持超时时间的设置,而Object不支持
1. Condition接口提供的方法
1.1 await方法
void await() throws InterruptedException
当前线程进入等待状态,如果其他线程调用condition的signal或者signalAll方法并且当前线程获取Lock从await方法返回,如果在等待状态中被中断会抛出被中断异常;
long awaitNanos(long nanosTimeout)
当前线程进入等待状态直到被通知,中断或者超时;
boolean await(long time, TimeUnit unit)throws InterruptedException
同第二种,支持自定义时间单位
boolean awaitUntil(Date deadline) throws InterruptedException
当前线程进入等待状态直到被通知,中断或者到了某个时间
1.2 signal方法
void signal()
唤醒一个等待在condition上的线程,将该线程从等待队列中转移到同步队列中,如果在同步队列中能够竞争到Lock则可以从等待方法中返回。
void signalAll()
与1的区别在于能够唤醒所有等待在condition上的线程。
2. Condition在ReentrantLock中的使用
下面先通过一个例子看一下Condition的使用 👇
1、大致流程就是线程1先获取lock之后,执行线程1的方法,然后调用condition.await();方法阻塞当前线程;同时加入Condition等待队列
2、线程1释放lock之后,线程2而已经在同步队列中了,线程2获取lock执行权,执行condition.signal()方法唤醒线程1
3、线程1被唤醒之后,node节点重新添加到同步队列中,等待获取执行权限,在线程2调用了unlock()方法之后,线程1重新获取到lock之后,执行后续流程。
1 | public class ReentrantLockDemo { |
上面代码的执行结果可以猜想一下
1 | enter thread 1 |
3. Condition等待/通知实现原理
要想能够深入的掌握condition还是应该知道它的实现原理,现在我们一起来看看condiiton的源码。创建一个condition对象是通过lock.newCondition()
,而这个方法实际上是会new出一个ConditionObject对象,该类是AQS的一个内部类,和Node类一样,非常重要。
condition是要和lock配合使用的也就是condition和Lock是绑定在一起的,而lock的实现原理又依赖于AQS,自然而然ConditionObject作为AQS的一个内部类无可厚非。
我们知道在锁机制的实现上,AQS内部维护了一个同步队列,如果是独占式锁的话,所有获取锁失败的线程的尾插入到同步队列,同样的,condition内部也是使用同样的方式,内部维护了一个 等待队列,所有调用condition.await方法的线程会加入到等待队列中,并且线程状态转换为等待状态。
另外注意到ConditionObject中有两个成员变量:
private transient Node firstWaiter;
private transient Node lastWaiter;
在AQS中condition队列可以存在多个如下所示,但是同步队列之可能是一个,值得注意的是,同步队列是一个双向链表队列,而等待队列是一个单向的队列。
下面从await方法入手来学习Condition的机制是如何运转的。
3.1 等待await
public class ConditionObject implements Condition
AQS#ConditionObject内部类实现了Condition接口的await方法:
1 | public final void await() throws InterruptedException { |
AQS#addConditionWaiter 添加节点到等待队列
1 | private Node addConditionWaiter() { |
这个方法应该比较好理解吧,就是添加一个节点,到等待队列。
⚠️ 这里和把节点添加到同步队列还有点区别,不知道大家还有没有印象,在同步队列添加节点的时候,先判断tail是否为空,如果不是空,则直接添加;如果是空,则调用了enq(Node node)
方法,先生成一个head节点,然后在把当前节点添加到后面,循环了两遍的。
这里是直接创建当前节点,然后将firstWaiter指针指向了node;
AQS#fullyRelease 释放lock
1 | final int fullyRelease(Node node) { |
这个方法也不难,想一下,线程都已经调用await方法了,而且上一步就已经把节点添加到了等待队列中了,那么接下来要做什么呢?那肯定是释放锁lock了。对,这个方法就是做这个的。release方法之前已经介绍了,无非就是对state做一下减法,把对战线程清空一下,给新来的线程腾地方。
下面才是await的关键核心代码:‼️
1 | while (!isOnSyncQueue(node)) { |
isOnSyncQueue(node)
判断当前节点是否在同步队列中,为什么要这个判断呢?原因很简单,当别的线程或者自己调用了signal方法之后,会把当前节点转移到同步队列中,在同步队列中说明什么呢,说明接下来这个线程要去竞争锁了,也就是被唤醒了,当竞争锁成功之后,这个线程就可以await后面的方法了。
(interruptMode = checkInterruptWhileWaiting(node)) != 0
如果当前线程被中断,则可以直接跳出循环,去竞争锁。
3.2 通知signal
调用condition的signal或者signalAll方法可以将等待队列中等待时间最长的节点移动到同步队列中,使得该节点能够有机会获得lock。按照等待队列是先进先出(FIFO)的,所以等待队列的头节点必然会是等待时间最长的节点,也就是每次调用condition的signal方法是将头节点移动到同步队列中。signal方法源码为:
1 | public final void signal() { |
signal方法首先会检测当前线程是否已经获取lock,如果没有获取lock会直接抛出异常,如果获取的话再得到等待队列的头指针引用的节点,之后的操作的doSignal方法也是基于该节点。下面我们来看看doSignal方法做了些什么事情。
AQS#doSignal
1 | private void doSignal(Node first) { |
具体逻辑请看注释,真正对头节点做处理的逻辑在transferForSignal放,该方法源码为:
1 | final boolean transferForSignal(Node node) { |
关键逻辑请看注释,这段代码主要做了两件事情
1.将头结点的状态更改为CONDITION;
2.调用enq方法,将该节点尾插入到同步队列中,并且把前驱节点的状态设置成Node.SIGNAL
现在我们可以得出结论:调用condition的signal的前提条件是当前线程已经获取了lock,该方法会使得等待队列中的头节点即等待时间最长的那个节点移入到同步队列,而移入到同步队列后才有机会使得等待线程被唤醒,即从await方法中的LockSupport.park(this)方法中返回,从而才有机会使得调用await方法的线程成功退出。
signalAll方法通知所有等待线程
sigllAll与sigal方法的区别体现在doSignalAll方法上,前面我们已经知道doSignal方法只会对等待队列的头节点进行操作,而doSignalAll的源码为:
1 | private void doSignalAll(Node first) { |
该方法只不过时间等待队列中的每一个节点都移入到同步队列中,即“通知”当前调用condition.await()方法的每一个线程。
面试题 两个线程交替顺序打印1~100
1 | package com.ibli.note; |