Java同步器之Condition源码分析
一、概述
条件锁就是指在获取锁之后发现当前业务场景自己无法处理,而需要等待某个条件的出现才可以继续处理时使用的一种锁。
比如,在阻塞队列中,当队列中没有元素的时候是无法弹出一个元素的,这时候就需要阻塞在条件notEmpty
上,等待其它线程往里面放入一个元素后,唤醒这个条件notEmpty
,当前线程才可以继续去做“弹出一个元素”的行为。
注意,这里的条件,必须是在获取锁之后去等待,对应到ReentrantLock
的条件锁,就是获取锁之后才能调用condition.await()
方法。
在Java
中,条件锁的实现都在AQS
的ConditionObject
类中,ConditionObject
实现了Condition
接口,所以ReentrantLock
的条件锁是基于AQS
实现的。
sychronized + Object.wait = Lock + Condition
二、案例
public class ReentrantLockTest {
public static void main(String[] args) throws InterruptedException {
// 声明一个重入锁
ReentrantLock lock = new ReentrantLock();
// 声明一个条件锁
Condition condition = lock.newCondition();
// 创建一个线程并执行,该线程就是当达到条件锁条件后,来执行后续的相关逻辑的。
// 可以看作是一个消费者
new Thread(() -> {
try {
// 获取锁
lock.lock(); // 1
try {
System.out.println("before await"); // 2
// 等待条件
// 该线程执行到这里就会进入到阻塞状态,直到达到了条件后,
// 由其他线程执行signal()方法来告知该线程已经达到条件了,
// 该线程就会在这里被唤醒继续向下执行
condition.await(); // 3
System.out.println("after await"); // 10
} finally {
// 释放锁
lock.unlock(); // 11
}
} catch (InterruptedException e) {
e.printStackTrace();
}
}).start();
// 这里睡1000ms是为了让上面的线程先获取到锁
Thread.sleep(1000);
// main方法的当前线程来获取锁,该线程就是用来进行相关业务处理,进而达到条件锁条件的。
// 可以看作是一个生产者
lock.lock(); // 4
try {
// 这里睡2000ms代表这个线程执行业务需要的时间,
// 当完成这里的2000ms之后就认为是符合条件锁条件了
Thread.sleep(2000); // 5
System.out.println("before signal"); // 6
// 通知条件已成立
condition.signal(); // 7
System.out.println("after signal"); // 8
} finally {
// 释放锁
lock.unlock(); // 9
}
}
}
上面的代码很简单,一个线程等待条件,另一个线程通知条件已成立,后面的数字代表代码实际运行的顺序。
由上面的例子我们也可以看出,await()
和signal()
方法都必须在获取锁之后释放锁之前使用;
三、源码分析
3.1 Condition接口
Condition
是一个接口,从1.5
的时候出现的,是用来替代Object
的wait
、notify
。所以显而易见,Condition
的await
和signal
肯定效率更高、安全性更好。Condition
是依赖于lock
实现的。并且await
和signal
只能在lock
的保护之内使用。
package java.util.concurrent.locks;
import java.util.concurrent.TimeUnit;
import java.util.Date;
public interface Condition {
//导致当前线程等到发信号或 interrupted 。
void await() throws InterruptedException;
//使当前线程等待直到发出信号
void awaitUninterruptibly();
//使当前线程等待直到发出信号或中断,或指定的等待时间过去。
long awaitNanos(long nanosTimeout) throws InterruptedException;
//使当前线程等待直到发出信号或中断,或指定的等待时间过去。
boolean await(long time, TimeUnit unit) throws InterruptedException;
//使当前线程等待直到发出信号或中断,或者指定的最后期限过去。
boolean awaitUntil(Date deadline) throws InterruptedException;
//唤醒一个等待线程。
void signal();
//唤醒所有等待线程。
void signalAll();
}
3.2 内部类
ConditionObject
是Condition
的实现类。
//AbstractQueuedSynchronizer.ConditionObject
public class ConditionObject implements Condition, java.io.Serializable {
/** First node of condition queue. */
private transient Node firstWaiter;
/** Last node of condition queue. */
private transient Node lastWaiter;
//...
}
可以看到条件锁中也维护了一个队列,为了和AQS
的队列区分,我这里称为条件队列,firstWaiter
是队列的头节点,lastWaiter
是队列的尾节点。
ConditionObject
中的条件队列和AQS
中的同步队列使用的是相同的节点类型Node
,但是两个队列还是有一些不同的,在后续会详细讲解。
3.3 lock.newCondition()方法
新建一个条件锁。
- ReentrantLock.newCondition()
- ReentrantLock.Sync.newCondition()
- AbstractQueuedSynchronizer.ConditionObject.ConditionObject()
public class ReentrantLock implements Lock, java.io.Serializable {
private final Sync sync;
// 创建条件锁
public Condition newCondition() {
return sync.newCondition();
}
/**
* 抽象内部类
*/
abstract static class Sync extends AbstractQueuedSynchronizer {
// 条件锁
final ConditionObject newCondition() {
return new ConditionObject();
}
}
}
// AbstractQueuedSynchronizer.ConditionObject.ConditionObject()
public ConditionObject() { }
新建一个条件锁最后就是调用的AQS
中的ConditionObject
类来实例化条件锁。
3.4 condition.await()方法
condition.await()
方法,表明现在要等待条件的出现,只有满足条件之后获取锁的线程才可以继续向后执行。
await()
方法会新建一个节点放到条件队列中,接着完全释放锁,然后阻塞当前线程并等待条件的出现;
// AbstractQueuedSynchronizer.ConditionObject.await()
public final void await() throws InterruptedException {
// 如果线程中断了,抛出异常
if (Thread.interrupted())
throw new InterruptedException();
// 添加节点到Condition的队列中,并返回该节点
Node node = addConditionWaiter();
// 完全释放当前线程获取的锁
// 因为锁是可重入的,所以这里要把获取的锁全部释放
int savedState = fullyRelease(node);
/**
* 中断标志,用来标识线程是否是被中断唤醒的
* interruptMode = 0:表示不是被中断唤醒的
* interruptMode != 0:表示是被中断唤醒的
* interruptMode = REINTERRUPT = 1:表示当前线程在其他线程调用signal()之后被中断唤醒
* interruptMode = THROW_IE = -1:表示当前线程在其他线程调用signal()之前被中断唤醒
*/
int interruptMode = 0;
// 是否在同步队列中,如果该线程节点从条件队列移出到同步队列中,
// 说明当前已经满足条件,线程已经被唤醒,则跳出循环
while (!isOnSyncQueue(node)) {
// 阻塞当前线程
LockSupport.park(this);
// 上面部分是调用await()时释放自己占有的锁,并阻塞自己等待条件的出现
// *************************分界线************************* //
// 下面部分是条件已经出现,该线程被唤醒,尝试重新去获取锁继续向后执行
// checkInterruptWhileWaiting()中会判断当前线程是否是被中断唤醒的
// 返回值非0表示是被中断唤醒的,会通过break跳出while。
// 因为如果是中断唤醒的,有可能实际上该线程还没有等到条件满足的时候就被唤醒了,
// 这样该线程的Node节点一定没有被转移到同步队列中,所以就不可能通过循环条件来跳出循环。
// 只能是我们手动调用break来跳出循环,毕竟await()方法还是要响应中断的,
// 不能在其他线程已经发出中断信号后,还让线程在这个循环里自选而不响应中断。
if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
break;
}
// 尝试获取锁,注意第二个参数,这里需要获取所的数量要和该线程最初持有锁的数量相同,
// 使该线程恢复到最开始的持有锁的状态
/**
* 我们从两个条件分别去分析
* 1、acquireQueued(node, savedState)
* 尝试获取锁,注意第二个参数,这里需要获取所的数量要和该线程最初持有锁的数量相同,
* 使该线程恢复到最开始的持有锁的状态,
* 该方法在之前ReentrantLock章节中已经讲解过了,在这个方法中线程就会不断地尝试获取锁,
* 如果没获取到就会再次阻塞在这个位置,等到被唤醒后继续抢占锁,直到成功获取锁之后该方法才会返回。
* 该方法的返回值是中断标记,如果该线程是被中断信号唤醒并且抢占到锁的,就会返回true,
* 如果线程不是被中断唤醒的,则返回false。
*
* 2、interruptMode != THROW_IE
* interruptMode标识的是线程在等待条件满足被阻塞的过程当中,是否是被中断唤醒的
* 这里的条件interruptMode != THROW_IE表示该线程不是在其他线程调用signal()之前被中断唤醒的
* 所以第一个条件是表示该线程在重新获取锁的时被阻塞,然后又被唤醒重新获取到锁的过程中,是不是被中断唤醒的
* 第二个条件表示该线程被阻塞,等待条件满足的过程当中,是不是被中断唤醒的
* 第一个条件为true,说明该线程是在重新获取锁的过程中接收到过中断信号,也就说是这一次中断是在该线程等待
* 条件被阻塞然后又被唤醒之后才发生的,这个中断信号一定是发生在其他线程调用signal()之后
* 第二个条件为true,说明该线程在其他线程调用signal之前没有接收到过中断信号
* 当两个条件都为true时,就会进入到if代码块中,将interruptMode = REINTERRUPT,也就是该线程收到了中断信号,
* 并且是在其他线程调用signal()之后收到的中断信号
* 如果该线程实在signal之前被中断的,那么该线程的流程就到此结束了,需要从头再来获取锁,
* 就不能执行后续的步骤了,也就不能进入到该if代码块中
*/
// 如果没获取到会再次阻塞
if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
interruptMode = REINTERRUPT;
// 清除取消的节点
if (node.nextWaiter != null) // clean up if cancelled
unlinkCancelledWaiters();
// 线程中断相关
if (interruptMode != 0)
reportInterruptAfterWait(interruptMode);
}
// AbstractQueuedSynchronizer.ConditionObject.addConditionWaiter
// 为线程创建Node节点并将其添加到条件队列当中去
private Node addConditionWaiter() {
Node t = lastWaiter;
/**
* 如果条件队列的尾节点已取消(非Node.CONDITION状态),从头节点开始清除所有已取消的节点
*
* 该条件成立的例子:
* 1、假设有两个线程thread0、thread1,初始时,thread0在未持有锁的情况下调用AQS.CO.await(),
* thread0执行到AQS.fullyRelease中时会将其对应节点的waitStatus字段设置为取消状态,
* 之后持有锁的thread1调用 AQS.CO.await(),会执行到这里,这是条件队列尾节点t.waitStatus为1
*
* 2、假设有两个线程thread0、thread1,初始时,thread0持有锁,
* 之后调用AQS.CO.await()释放锁并阻塞在LockSupport.park(this)处,
* 之后外部线程中断thread0,thread0被唤醒后会执行到AQS.transferAfterCancelledWait的if处
* 将t.waitStatus设置为0,之后thread1获取到锁,执行到这里时,t.waitStatus为0
*/
if (t != null && t.waitStatus != Node.CONDITION) {
// 移除条件队列中所有不是Node.CONDITION状态的节点
unlinkCancelledWaiters();
// 重新获取最新的尾节点,经过unlinkCancelledWaiters(),lastWaiter可能已经改变
t = lastWaiter;
}
// 新建一个节点,它的等待状态是CONDITION
Node node = new Node(Thread.currentThread(), Node.CONDITION);
// 如果尾节点为空,则把新节点赋值给头节点(相当于初始化队列)
// 否则把新节点赋值给尾节点的nextWaiter指针
if (t == null)
firstWaiter = node;
else
t.nextWaiter = node;
// 尾节点指向新节点
lastWaiter = node;
// 返回新节点
return node;
}
// AbstractQueuedSynchronizer.fullyRelease
// 完全释放当前线程获取的锁
final int fullyRelease(Node node) {
boolean failed = true;
try {
// 获取状态变量的值,重复获取锁,这个值会一直累加
// 所以这个值也代表着获取锁的次数
int savedState = getState();
// 一次性释放所有获得的锁
if (release(savedState)) {
failed = false;
// 返回获取锁的次数
return savedState;
} else {
throw new IllegalMonitorStateException();
}
} finally {
if (failed)
node.waitStatus = Node.CANCELLED;
}
}
// AbstractQueuedSynchronizer.isOnSyncQueue
// 判断当前线程节点是否在同步队列中
final boolean isOnSyncQueue(Node node) {
// 如果等待状态是CONDITION,或者前一个指针为空,返回false
// 说明还没有移到AQS的队列中
if (node.waitStatus == Node.CONDITION || node.prev == null)
return false;
// 如果next指针有值,说明已经移到AQS的队列中了
if (node.next != null) // If has successor, it must be on queue
return true;
// 从AQS的尾节点开始往前寻找看是否可以找到当前节点,找到了也说明已经在AQS的队列中了
return findNodeFromTail(node);
}
// AbstractQueuedSynchronizer.findNodeFromTail()
private boolean findNodeFromTail(Node node) {
Node t = tail;
for (;;) {
if (t == node)
return true;
if (t == null)
return false;
t = t.prev;
}
}
// AbstractQueuedSynchronizer.ConditionObject.checkInterruptWhileWaiting()
// 根据节点的中断情况来返回其中断标志
private int checkInterruptWhileWaiting(Node node) {
/**
* 通过Thread.interrupted()来判断该线程是不是被中断,如果没有被中断则返回0
* 如果被中断了,则在通过transferAfterCancelledWait(node)来判断该线程是在其他线程调用signal()前被中断,
* 还是调用signal()后被中断
* 返回THROW_IE表示当前线程在其他线程调用signal前被中断
* 返回REINTERRUPT表示当前线程在其他线程调用signal后被中断
* 具体的分界点就是node.waitStatus的值,若其值为Node.CONDITION,是signal前被中断,否则在signal后被中断
*/
return Thread.interrupted()
? (transferAfterCancelledWait(node) ? THROW_IE : REINTERRUPT)
: 0;
}
// AbstractQueuedSynchronizer.ConditionObject.transferAfterCancelledWait()
// 返回true表示该节点是在调用signal()之前被中断的,返回false表示是调用signal()之后被中断的
final boolean transferAfterCancelledWait(Node node) {
/**
* 如果node.waitStatus的值是Node.CONDITION,说明该节点还没有被signal()方法唤醒,
* 也就是说该节点是在调用signal()前被中断的
*
* 例子:
* 该条件为true的情形:
* 假设仅有thread0,thread0持有锁后调用AQS.CO.await()被park,
* 之后被外部线程中断,会执行到这里,此时条件为true
* 该条件为false的情形:
* 假设有两个线程thread0、thread1,thread0,thread0持有锁后调用AQS.CO.await()被park,
* thread1获取到锁后调用AQS.CO.signal,之后会执行到AQS.transferForSignal的第一个if处,
* 该if语句执行完后,这里node.waitStatus被修改为0,所以thread0执行这里的if语句时会失败
*/
if (compareAndSetWaitStatus(node, Node.CONDITION, 0)) {
// 被中断后就需要重新进入同步队列抢占锁,从头再来
enq(node);
return true;
}
// 到这里说明其他线程调用了signal(),将当前线程对应的节点加入同步队列,这里自旋等待入队完成
while (!isOnSyncQueue(node))
// 主动让出当前线程的CPU时间片
Thread.yield();
// 到这里就说明是在调用signal()之后被中断的,执行到这里的时候,这个线程节点已经进入到了同步队列中了,
// 在后续的操作中就会执行acquireQueued(node, savedState)来不断尝试获取锁直到成功
return false;
}
// AbstractQueuedSynchronizer.ConditionObject.unlinkCancelledWaiters()
// 清除掉条件队列中所有被取消的节点;
private void unlinkCancelledWaiters() {
// 获取条件队列的头节点
Node t = firstWaiter;
Node trail = null;
/**
* 1、从firstWaiter开始,将整个链表中t.waitStatus != Node.CONDITION的节点移除掉;
* 2、节点移除后,将其前置节点的nextWaiter指向后置节点。
*/
while (t != null) {
// 获取当前遍历到节点的下一个节点
Node next = t.nextWaiter;
if (t.waitStatus != Node.CONDITION) {
/*
* 当前节点状态不是CONDITION:
* 将当前节点的nextWaiter设置为null。
* 如果trail是空,则将firstWaiter指向之前保存的t.nextWaiter,
* 否则将trail.nextWaiter指向之前保存的t.nextWaiter。
*/
t.nextWaiter = null;
if (trail == null)
firstWaiter = next;
else
trail.nextWaiter = next;
if (next == null)
lastWaiter = trail;
}
else
trail = t;
t = next;
}
}
// AbstractQueuedSynchronizer.ConditionObject.reportInterruptAfterWait()
// 根据中断标识来进行不同的处理
private void reportInterruptAfterWait(int interruptMode) throws InterruptedException {
// 如果当前线程在其他线程调用signal()之前被中断唤醒,则直接抛出异常响应中断
if (interruptMode == THROW_IE)
throw new InterruptedException();
// 如果当前线程在其他线程调用signal()之后被中断唤醒,这种情况不会对条件锁流程造成影响,
// 则设置中断标志,但不会抛出异常中止执行
else if (interruptMode == REINTERRUPT)
selfInterrupt();
}
这里有几个难理解的点:
-
Condition
的队列和AQS
的队列不完全一样;AQS
的队列头节点是不存在任何值的,是一个虚节点;Condition
的队列头节点是存储着实实在在的元素值的,是真实节点。
-
各种等待状态(
waitStatus
)的变化;- 首先,在条件队列中,新建节点的初始等待状态是
CONDITION(-2)
; - 其次,移到
AQS
的队列中时等待状态会更改为0(AQS队列节点的初始等待状态为0); - 然后,在
AQS
的队列中如果需要阻塞,会把它上一个节点的等待状态设置为SIGNAL(-1)
; - 最后,不管在
Condition
队列还是AQS
队列中,已取消的节点的等待状态都会设置为CANCELLED(1)
; - 另外,后面我们在共享锁的时候还会讲到另外一种等待状态叫
PROPAGATE(-3)
。
- 首先,在条件队列中,新建节点的初始等待状态是
-
相似的名称;
AQS
中下一个节点是next
,上一个节点是prev
;Condition
中下一个节点是nextWaiter
,没有上一个节点。
总结一下await()
方法的大致流程:
- 新建一个节点加入到条件队列中去;
- 完全释放当前线程占有的锁;
- 阻塞当前线程,并等待条件的出现;
- 条件已出现(此时节点已经移到
AQS
的队列中),尝试获取锁;
也就是说await()
方法内部其实是先释放锁->等待条件->再次获取锁的过程。
3.5 condition.signal()方法
condition.signal()
方法通知条件已经出现。
这个方法是由获取锁的其他线程执行的,用来唤醒正在阻塞等待满足条件的线程。
signal()
方法会寻找条件队列中第一个可用节点移到AQS队列中;
// AbstractQueuedSynchronizer.ConditionObject.signal
public final void signal() {
// 如果不是当前线程占有着锁,调用这个方法抛出异常
// 说明signal()也要在获取锁之后执行
if (!isHeldExclusively())
throw new IllegalMonitorStateException();
// 条件队列的头节点
Node first = firstWaiter;
// 如果有等待条件的节点,则通知它条件已成立
if (first != null)
doSignal(first);
}
// AbstractQueuedSynchronizer.ConditionObject.doSignal
private void doSignal(Node first) {
// 从头节点开始遍历条件队列,仅唤醒第一个符合条件的线程
do {
// 将记录条件队列头节点的指向向后移动一位
if ( (firstWaiter = first.nextWaiter) == null)
// 如果移动后firstWaiter为null,说明已到队列尾部,将lastWaiter设置为null
lastWaiter = null;
// 将first与其后继节点断开,相当于把头节点从队列中出队
first.nextWaiter = null;
// 转移节点到AQS队列中
// 条件1:只要一个线程转移到AQS同步队列成功,transferForSignal返回true,就会终止该循环
// 条件2:用于判断是否遍历到了队列尾部
} while (!transferForSignal(first) &&
(first = firstWaiter) != null);
}
// AbstractQueuedSynchronizer.transferForSignal
// 将节点从条件队列移动到同步队列,返回移动是否成功
final boolean transferForSignal(Node node) {
// 把节点的状态更改为0,也就是说即将移到AQS队列中
// 如果失败了,说明节点已经被改成取消状态了
// 返回false,通过上面的循环可知会寻找下一个可用节点
if (!compareAndSetWaitStatus(node, Node.CONDITION, 0))
return false;
// 调用AQS的入队方法把节点移到AQS的队列中
// 注意,这里enq()的返回值是node的上一个节点,也就是旧尾节点
Node p = enq(node);
// 上一个节点的等待状态
int ws = p.waitStatus;
// 如果上一个节点已取消了,或者更新状态为SIGNAL失败(也是说明上一个节点已经取消了)
// 则直接唤醒当前节点对应的线程
if (ws > 0 || !compareAndSetWaitStatus(p, ws, Node.SIGNAL))
LockSupport.unpark(node.thread);
// 如果更新上一个节点的等待状态为SIGNAL成功了
// 则返回true,这时上面的循环不成立了,退出循环,也就是只通知了一个节点
// 此时当前节点还是阻塞状态
// 也就是说调用signal()的时候并不会真正唤醒一个节点
// 只是把节点从条件队列移到AQS队列中
return true;
}
signal()
方法的大致流程为:
- 从条件队列的头节点开始寻找一个非取消状态的节点;
- 把它从条件队列移到
AQS
队列; - 且只移动一个节点;
注意,这里调用signal()
方法后并不会真正唤醒一个节点,那么,唤醒一个节点是在啥时候呢?
我们可以再回去看一下本文最开始的使用案例,在其他线程调用signal()
方法后,该线程最终会执行lock.unlock()
方法,此时才会真正唤醒一个正在同步队列中的节点,唤醒的这个节点如果曾经是条件节点被转移到条件队列中的话,就会继续执行await()方法“分界线”下面的代码。也就是说,在调用signal()方法的线程调用unlock()方法才是真正唤醒阻塞在条件上的节点(此时节点已经在AQS队列中);被唤醒之后,被唤醒的节点会再次尝试获取锁,后面的逻辑与lock()的逻辑基本一致了。
3.6 condition.signalAll()方法
signalAll
与signal
类似,区别是signalAll
会将所有节点加入同步队列,除了doSignalAll
方法以外,其他的方法都是一样的:
private void doSignalAll(Node first) {
// 将条件队列的头节点和尾节点都置为null
lastWaiter = firstWaiter = null;
// 遍历条件队列,依次唤醒所有线程
do {
Node next = first.nextWaiter;
first.nextWaiter = null;
transferForSignal(first);
first = next;
} while (first != null);
}
四、总结
- 条件锁是指为了等待某个条件出现而使用的一种锁;
- 条件锁比较经典的使用场景就是队列为空时阻塞在条件notEmpty上;
- ReentrantLock中的条件锁是通过AQS的ConditionObject内部类实现的;
- await()和signal()方法都必须在获取锁之后释放锁之前使用;
- await()方法会新建一个节点放到条件队列中,接着完全释放锁,然后阻塞当前线程并等待条件的出现;
- signal()方法会寻找条件队列中第一个可用节点移到AQS队列中;
- 在调用signal()方法的线程调用unlock()方法才真正唤醒阻塞在条件上的节点(此时节点已经在AQS队列中);
- 之后该节点会再次尝试获取锁,后面的逻辑与lock()的逻辑基本一致了。