在AQS中存在两个FIFO队列：同步队列 和 等待队列。本篇文章主要是讲condition实现原理(即等待队里)，同步队列实现原理看这篇文章：深入理解AQS实现原理和源码分析。等待队列是由Condition内部实现的，是一个虚拟的FIFO单向队列，在AQS中同步队列、等待队列组成关系如下图：
-
(1)AQS中tail 和 head主要构成了一个FIFO双向的同步队列。
-
(2)AQS中condition构成了一个FIFO单向等待队列。condition是AQS内部类，每个Condition对象中保存了firstWaiter和lastWaiter作为队列首节点和尾节点，每个节点使用Node.nextWaiter保存下一个节点的引用，因此等待队列是一个单向队列。
1.队列关系
在Object的监视器(monitor)模型上，一个对象拥有一个同步队列和一个等待队列；而并发包中的AQS上拥有一个同步队列和多个等待队列。两者的具体实现原理的有所不同，但在多线程下等待/唤醒 操作的思路有相同之处，Object的监视器模型 和 AQS对同步队列、等待队列对应关系如下图
（1）Object的监视器模型同步、等待队列对应关系图
多个线程并发访问某个对象监视器(Monitor对象)的时候，即多线程执行Synchonized处的代码时，monitor处理过程包括：
-
(1)thread进入Synchonized代码时，会执行Monitor.Enter命令来获取monitor对象。如果命令执行成功获取Monitor对象成功，执行失败线程会进入synchronized同步队列中，线程处于BLOCKED，直到monitor对象被释放。
-
(2)thread执行完Synchonized同步代码块后，会执行Monitor.exit命令来释放monitor对象，并通知同步队列会获取monitor对象。
-
(3)如果线程执行object.wait()，线程会进入synchronized等待队列进行WAITING，直到其他线程线程执行notify()或notifyAll()方法，将等待队列中的一个或多个等待线程从等待队列中移到同步队列中，被移动的线程状态由WAITING变为BLOCKED。
（2）AQS中同步、等待队列对应关系图
当多线程并发访问AQS的lock()、await()、single()方法时，同步队列和等待队列变化处理过程包括：
- （1）多个形成执行lock()方法时，线程会竞争获取同步锁state，获取成功的线程占有锁state、获取失败的线程会封装成node加入到AQS的同步队列中，等待锁state的释放。
- （2）等获取了state锁的线程(同步队列中head节点)执行await()方法时，condition会将当前线程封装成一个新的node添加到condition等待队列的尾部，同时阻塞(waiting)，直到被唤醒。
- （3）等获取了state锁的线程(同步队列中head节点)single()方法时，condition会将等待队列首节点移动到同步队列的尾部，直到获取同步锁state才被唤醒。
两者的对比关系图：
2.Condition的实现
（1）等待的实现
当线程调用Condition.await()方法时，将会把前线程封装成node节点，并将节点加入等待队列的尾部，然后释放同步state状态，唤醒同步队列中的后继节点，然后当前线程会进入等待状态。当前线程加入Condition的等待队列逻辑如下图：
-
（1）能够调用Condition.await()方法的节点是获取了同步state锁的node，即同步队列中的head节点；调用Condition的await()方法(或者以await开头的方法)会使当前线程进入等待队列并释放锁、唤醒同步队列中的后继节点，最后线程状态变为等待状态。
-
（2）Condition拥有首尾节点的引用，而新增节点只需要将原有的尾节点nextWaiter指向它，并且更新尾节点即可。
-
（3）调用Condition.await()节点引用更新的过程并没有使用CAS保证，原因在于调用await()方法的线程必定是获取了state锁的线程，也就是说该过程是由锁来保证线程安全的。
注意：同步队列的首节点并不会直接加入等待队列，而是把当前线程构封装成一个新的节点并将其加入等待队列中。
await()方法源码
整个await()的执行的过程可以总结如下几步：
-
（1）将当前线程封装成node加入Condition等待队列尾部。
-
（2）释放state锁：不管重入几次，都把state释放为0，同时唤醒同步队列的后继节点。
-
（3）自旋：直到node节点在等待队列上的节点移动到了同步队列（通过其他线程调用signal()）或被中断。
-
（4）阻塞当前节点，直到node获取到了锁，也就是node在同步队列上的节点排队排到了队首。
-
public final void await() throws InterruptedException {
-
//如果当前线程中断，抛出异常
-
if (Thread.interrupted())
-
throw
new InterruptedException();
-
//1.将当前线程封装成一个node并加入到等待队列队尾(这里如果lastWaiter是CANCELLED取消状态，那么会把它踢出Condition队列)。
-
Node node = addConditionWaiter();
-
//2.释放当前线程的独占锁，不管重入几次，都把state释放为0
-
int savedState = fullyRelease(node);
-
int interruptMode =
0;
-
//3.判断当前节点没有在同步队列上，没有在同步队列上(即还没有被signal)，则将当前线程阻塞
-
while (!isOnSyncQueue(node)) {
-
LockSupport.park(
this);
-
//4.判断标记两种中断：是在被signal前中断还是在被signal后中断,分别标记上THROW_IE和REINTERRUPT。
-
if ((interruptMode = checkInterruptWhileWaiting(node)) !=
0)
-
break;
-
}
-
//5.这个时候线程已经被signal()或者signalAll()操作给唤醒了，退出了3中的while循环自旋等待，尝试再次获取锁
-
if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
-
interruptMode = REINTERRUPT;
-
if (node.nextWaiter !=
null)
// clean up if cancelled 清除等待队列中等待状态不为CONDITION的节点
-
unlinkCancelledWaiters();
-
//6.在第4步中标记的中断状态，如果是在被signal前中断还是在被signal后中断，如果是被signal前就被中断则抛出 InterruptedException，否则执行 Thread.currentThread().interrupt();
-
if (interruptMode !=
0)
-
reportInterruptAfterWait(interruptMode);
-
}
addConditionWaiter源码
-
//addConditionWaiter()方法主要是将线程封装成节点，添加到等待队列尾部
-
private Node addConditionWaiter() {
-
Node t = lastWaiter;
-
//Condition里面的节点状态不是等待状态CONDITION时，会清除节点
-
if (t !=
null && t.waitStatus != Node.CONDITION) {
-
unlinkCancelledWaiters();
-
t = lastWaiter;
-
}
-
//将当前线程分装成一个node，加到等待多了尾部
-
Node node =
new Node(Thread.currentThread(), Node.CONDITION);
-
if (t ==
null)
-
firstWaiter = node;
-
else
-
t.nextWaiter = node;
-
lastWaiter = node;
-
return node;
-
}
-
//从等待队列头部开始循环清除等待状态waitStatus不为CONDITION的节点
-
private void unlinkCancelledWaiters() {
-
Node t = firstWaiter;
-
Node trail =
null;
-
while (t !=
null) {
-
Node next = t.nextWaiter;
-
if (t.waitStatus != Node.CONDITION) {
-
t.nextWaiter =
null;
-
if (trail ==
null)
-
firstWaiter = next;
-
else
-
trail.nextWaiter = next;
-
if (next ==
null)
-
lastWaiter = trail;
-
}
-
else
-
trail = t;
-
t = next;
-
}
-
}
fullyRelease()源码
fullyRelease()方法中会调用release()释放掉state锁，不管重入几次，都把state释放为0，同时唤醒同步队列的后继节点。
-
final int fullyRelease(Node node) {
-
boolean failed =
true;
-
try {
-
//获取持有state锁的次数
-
int savedState = getState();
-
//把state释放为0
-
if (release(savedState)) {
-
failed =
false;
-
return savedState;
-
}
else {
-
throw
new IllegalMonitorStateException();
-
}
-
}
finally {
-
//释放锁失败，再将node设置为CANCELLED状态
-
if (failed)
-
node.waitStatus = Node.CANCELLED;
-
}
-
}
isOnSyncQueue()源码
isOnSyncQueue()方法主要是判断node是不是在同步队列中，只有在同步队列中的线程才会被阻塞。
-
final boolean isOnSyncQueue(Node node) {
-
//如果当前节点状态是CONDITION或node.prev是null，则证明当前节点在等待队列上而不是同步队列上。用node.prev来判断，是因为一个节点如果要加入同步队列，在加入前就会设置好prev字段。
-
if (node.waitStatus == Node.CONDITION || node.prev ==
null)
-
return
false;
-
//如果node.next不为null，则一定在同步队列上，因为node.next是在节点加入同步队列后设置的
-
if (node.next !=
null)
// If has successor, it must be on queue
-
return
true;
-
//从等待队列的尾部遍历判断node是否在等待队列中
-
return findNodeFromTail(node);
-
}
-
-
private boolean findNodeFromTail(Node node) {
-
Node t = tail;
-
for (;;) {
-
if (t == node)
-
return
true;
-
if (t ==
null)
-
return
false;
-
t = t.prev;
-
}
-
}
reportInterruptAfterWait()方法源码
reportInterruptAfterWait()方法会根据中断状态来判断是抛出异常，还是执行中断。即判断线程是在被signal前中断，还是在被signal后中断；如果是被signal前就被中断则抛出 InterruptedException，否则执行 Thread.currentThread().interrupt()。
-
private void reportInterruptAfterWait(int interruptMode)
-
throws InterruptedException {
-
//如果是在调signal()前就被中断则抛出异常
-
if (interruptMode == THROW_IE)
-
throw
new InterruptedException();
-
//如果是在调signal()方法后中断，就执行中断
-
else
if (interruptMode == REINTERRUPT)
-
selfInterrupt();
-
}
到此condition的wait()方法分析就完了，可以看出，await()的操作过程和Object.wait()方法是一样，只不过await()采用了Condition等待队列的方式实现了Object.wait()的功能。
（2）通知的实现
调用Condition的signal()方法，将会唤醒在等待队列中等待时间最长的节点（首节点），在唤醒节点之前，会将等待队列中节点移到同步队列中。Condition的signal()方法将节点从等待队列移动到同步队列逻辑如下图：
整个signal()的过程可以总结如下：
-
（1）执行signal()唤醒线程时，先判断当前线程是否是同步锁state持有线程，所以能够调用signal()方法的线程一定持有了同步锁state。
-
（2）自旋唤醒等待队列的firstWaiter(首节点)，在唤醒firstWaiter节点之前，会将等待队列首节点移到同步队列中。
signal()源码
-
public final void signal() {
-
//判断当前线程是否是state锁持有线程
-
if (!isHeldExclusively())
-
throw
new IllegalMonitorStateException();
-
Node first = firstWaiter;
-
//等待队列首节点不为null时，唤醒首节点
-
if (first !=
null)
-
doSignal(first);
-
}
-
//自旋唤醒首节点
-
private void doSignal(Node first) {
-
do {
-
//移动头节点指针firstWaiter
-
if ( (firstWaiter = first.nextWaiter) ==
null)
-
lastWaiter =
null;
-
//从等待队列中移除首节点
-
first.nextWaiter =
null;
-
}
while (!transferForSignal(first)
//transferForSignal方法尝试唤醒当前节点，如果唤醒失败，则继续尝试唤醒
-
&& (first = firstWaiter) !=
null);
-
}
-
-
//尝试唤醒当前节点，并将当前节点移动到同步队列中
-
final boolean transferForSignal(Node node) {
-
//如果当前节点状态为CONDITION，则将状态改为0准备加入同步队列；如果当前状态不为CONDITION，说明该节点等待已被中断
-
if (!compareAndSetWaitStatus(node, Node.CONDITION,
0))
-
return
false;
-
//将node添加到同步队列中,返回的p是node节点在同步队列中的先驱节点
-
Node p = enq(node);
-
int ws = p.waitStatus;
-
//如果先驱节点的状态为CANCELLED(大于0) 或设置先驱节点的状态为SIGNAL失败，那么就立即唤醒当前节点对应的线程，线程被唤醒后会执行await()方法中的acquireQueued()方法，该方法会重新尝试将节点的先驱状态设为SIGNAL并再次park线程；如果当前设置前驱节点状态为SIGNAL成功，那么就不需要马上唤醒线程了，当它的前驱节点成为同步队列的首节点且释放同步状态后，会自动唤醒它。
-
if (ws >
0 || !compareAndSetWaitStatus(p, ws, Node.SIGNAL))
-
LockSupport.unpark(node.thread);
-
return
true;
-
}
signalAll()源码
signalAll()会从首节点循环遍历等待队列，将等待队列中的所有节点移到同步队列中去。
-
public final void signalAll() {
-
//判断当前线程是否是state锁持有线程
-
if (!isHeldExclusively())
-
throw
new IllegalMonitorStateException();
-
Node first = firstWaiter;
-
if (first !=
null)
-
doSignalAll(first);
-
}
-
//遍历等待队列，将等待队列中的node移动到同步队里中
-
private void doSignalAll(Node first) {
-
lastWaiter = firstWaiter =
null;
-
do {
-
Node next = first.nextWaiter;
-
first.nextWaiter =
null;
-
//移动节点到同步队里中
-
transferForSignal(first);
-
first = next;
-
}
while (first !=
null);
-
}
（3）总结
-
（1）Condition等待通知的本质就是等待队列 和 同步队列的交互的过程，跟object的wait()/notify()机制一样；Condition是基于同步锁state实现的，而objec是基于monitor模式实现的。
-
（2）一个lock(AQS)可以有多个Condition，即多个等待队列，只有一个同步队列。
-
（3）Condition.await()方法执行时，会将同步队列里的head锁释放掉，把线程封装成新node添加到等待队列中；Condition.signal()方法执行时，会把等待队列中的首节点移到同步队列中去，直到锁state被获取才被唤醒。
扫一扫
1125
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
