前两篇文章别离介绍了 AQS 框架中的独占模式和共享模式,本篇将介绍 AQS 对 Condition 接口的实现。
在浏览本篇之前,倡议先理解 AQS 中的数据结构和独占模式的实现原理。
JUC 通过 Lock 和 Condition 两个接口实现管程(Monitor),其中 Lock 用于解决互斥问题,而 Condition 用于解决同步问题,而 AQS 对 Lock 和 Condition 接口的实现提供了一个根底的框架。
1. Condition 接口
Lock 代替了 synchronized 办法和语句的应用,Condition 代替了 Object 监视器办法的应用。
Condition 实现能够提供不同于 Object 监视器办法的行为和语义,比方受保障的告诉排序,或者在执行告诉时不须要放弃一个锁。
如果某个实现提供了这样非凡的语义,则该实现必须记录这些语义。
办法摘要:
// 造成以后线程在接到信号或被中断之前始终处于期待状态。void await()
// 造成以后线程在接到信号、被中断或达到指定等待时间之前始终处于期待状态。boolean await(long time, TimeUnit unit)
// 造成以后线程在接到信号、被中断或达到指定等待时间之前始终处于期待状态。long awaitNanos(long nanosTimeout)
// 造成以后线程在接到信号之前始终处于期待状态。void awaitUninterruptibly()
// 造成以后线程在接到信号、被中断或达到指定最初期限之前始终处于期待状态。boolean awaitUntil(Date deadline)
// 唤醒一个期待线程。void signal()
// 唤醒所有期待线程。void signalAll()
Condition 实质上是一个队列(称为条件队列),线程期待某个条件成立时,在队列中阻塞,直到其余线程查看条件成立起初告诉它。
对于同一个锁,只会存在一个同步队列,然而可能会有多个条件队列,只有在应用了 Condition 才会存在条件队列。
AQS 中对条件队列的应用:
当线程获取锁之后,执行 Condition.await()
会开释锁并进入条件队列,阻塞期待直到被其余线程唤醒。
当其余线程执行 Condition.signal()
唤醒以后线程时,以后线程会从条件队列转移到同步队列来期待再次获取锁。
以后线程再一次获取锁之后,须要在 while 循环中判断条件是否成立,若不成立需从新执行 Condition.await()
去期待。
2. Condition 应用
Condition 实例本质上被绑定到一个锁上。要为特定 Lock 实例取得 Condition 实例,请应用其 newCondition() 办法。
Java 官网文档提供 Condition 接口的应用示例:
对于一个有界阻塞数组,当数组非满时才能够往数组中存放数据,否则阻塞;当数据非空时才能够往数组中取元素,否则阻塞。
class BoundedBuffer {final Lock lock = new ReentrantLock();
final Condition notFull = lock.newCondition();
final Condition notEmpty = lock.newCondition();
final Object[] items = new Object[100];
int putptr, takeptr, count;
// 生产者办法,往数组外面写数据
public void put(Object x) throws InterruptedException {lock.lock();
try {while (count == items.length)
notFull.await(); // 阻塞直到非满
items[putptr] = x;
if (++putptr == items.length) putptr = 0;
++count;
notEmpty.signal(); // 告诉非空} finally {lock.unlock();
}
}
// 消费者办法,从数组外面拿数据
public Object take() throws InterruptedException {lock.lock();
try {while (count == 0)
notEmpty.await(); // 阻塞直到非空
Object x = items[takeptr];
if (++takeptr == items.length) takeptr = 0;
--count;
notFull.signal(); // 告诉非满
return x;
} finally {lock.unlock();
}
}
}
在 JDK 的实现中,独占模式才可应用 Condition,共享模式不反对 Condition。
因为 AQS 的外部类 ConditionObject 只反对独占模式。
java.util.concurrent.locks.ReentrantLock.Sync#newCondition
final ConditionObject newCondition() {return new ConditionObject();
}
java.util.concurrent.locks.ReentrantReadWriteLock.WriteLock#newCondition
public Condition newCondition() {return sync.newCondition();
}
java.util.concurrent.locks.ReentrantReadWriteLock.ReadLock#newCondition
/**
* Throws {@code UnsupportedOperationException} because
* {@code ReadLocks} do not support conditions.
*
* @throws UnsupportedOperationException always
*/
public Condition newCondition() {throw new UnsupportedOperationException();
}
3. Condition 期待办法
3.1 Condition#await
代码流程:
- 判断线程是否被中断,如果是,间接抛出 InterruptedException,否则进入下一步
- 将以后线程封装为节点,存入条件队列。
- 开释以后线程已取得的全副的锁,若无持有锁则抛异样。
- 在条件队列中,阻塞以后节点。
- 以后节点从阻塞中被唤醒(signalled or interrupted),则会从条件队列转移到同步队列(被动或被动地)。
- 在同步队列中,自旋、阻塞期待获取锁胜利。
- 判断整个过程中是否产生过中断,进行不同的解决(抛异样 或 从新中断)。
java.util.concurrent.locks.AbstractQueuedSynchronizer.ConditionObject#await()
/**
* Implements interruptible condition wait.
* <ol>
* <li> If current thread is interrupted, throw InterruptedException.
* <li> Save lock state returned by {@link #getState}.
* <li> Invoke {@link #release} with saved state as argument,
* throwing IllegalMonitorStateException if it fails.
* <li> Block until signalled or interrupted.
* <li> Reacquire by invoking specialized version of
* {@link #acquire} with saved state as argument.
* <li> If interrupted while blocked in step 4, throw InterruptedException.
* </ol>
*/
public final void await() throws InterruptedException {if (Thread.interrupted())
throw new InterruptedException();
Node node = addConditionWaiter(); // 将以后线程封装成节点存入条件队列
int savedState = fullyRelease(node); // 开释曾经持有的锁(就是在调用 Condition#await 之前持有的 Lock#lock 锁),并返回开释前的锁状态
int interruptMode = 0;
while (!isOnSyncQueue(node)) { // 查看节点是否在同步队列上
LockSupport.park(this); // 节点还在条件队列中,则阻塞
// 节点从阻塞中被唤醒(condition#signal,Thread#interrupt),查看中断状态,设置中断解决模式
// 补充:被 condition#signal 唤醒后的线程会从条件队列转移到同步队列(先出队再入队)// 补充:若在条件队列中就产生了中断,也会被转移到同步队列(不出队,只入队,见 checkInterruptWhileWaiting -> transferAfterCancelledWait)if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
break;
}
if (acquireQueued(node, savedState) && interruptMode != THROW_IE) // 在同步队列期待获取资源直到胜利,判断设置中断解决模式
interruptMode = REINTERRUPT;
if (node.nextWaiter != null) // clean up if cancelled
// nextWaiter 不为空,阐明以后节点是由 Thread#interrupt 唤醒的(condition#signal 唤醒阻塞节点会设置 nextWaiter 为空)// 此时以后节点同时存在于同步队列、条件队列上!然而 waitStatus 不是 CONDITION
// 须要革除条件队列中已勾销的节点
unlinkCancelledWaiters();
if (interruptMode != 0)
reportInterruptAfterWait(interruptMode); // 解决中断:抛异样,或者补上中断状态
}
留神:
- 线程被唤醒,可能是执行了 Condition#signal(其中执行 LockSupport#unpark 来唤醒条件队列的头节点),也可能是调用了 Thread#interrupt (会更新线程的中断标识)。
- 如果是由 Condition#signal 唤醒的,则以后节点被唤醒后,曾经位于同步队列。
- 如果是由 Thread#interrupt 唤醒的,则以后节点被唤醒后,须要判断是位于同步队列还是条件队列。
3.1 如果是位于同步队列,阐明是先失去 Condition#signal 告诉,再被 Thread#interrupt 中断。
3.2 如果是位于条件队列,阐明未失去 Condition#signal 告诉就被 Thread#interrupt 中断了,须要自行退出到同步队列中,再从条件队列中移除。 - 以后节点从条件队列转移到同步队列的过程中,产生了中断,该节点依旧会在同步队列中自旋、阻塞直到获取锁,再响应中断(抛异样或从新中断)。
3.1.1 addConditionWaiter
将以后线程封装为节点(waitStatus 为 CONDITION),增加到条件队列尾部。
若条件队列不存在则进行初始化,把以后节点作为头节点(不应用 dummy node)。
java.util.concurrent.locks.AbstractQueuedSynchronizer.ConditionObject#addConditionWaiter
/**
* Adds a new waiter to wait queue.
* @return its new wait node
*/
private Node addConditionWaiter() {
Node t = lastWaiter;
// If lastWaiter is cancelled, clean out. // 清理条件队列中已勾销的尾节点
if (t != null && t.waitStatus != Node.CONDITION) {unlinkCancelledWaiters();
t = lastWaiter;
}
Node node = new Node(Thread.currentThread(), Node.CONDITION); // 构建节点,尾插法
if (t == null)
firstWaiter = node;
else
t.nextWaiter = node;
lastWaiter = node;
return node;
}
3.1.2 fullyRelease
开释以后线程已持有的锁 / 资源,返回开释之前的锁 / 资源。
若未持有锁,报错。
这里存在 BUG:报错之前,以后线程曾经退出到条件队列之中了,会导致条件队列存储有效的节点数据。
应该将是否持有锁的校验提前到 addConditionWaiter 之前,JDK 11 中已修复该问题。
java.util.concurrent.locks.AbstractQueuedSynchronizer#fullyRelease
final int fullyRelease(Node node) { // 开释以后线程已持有的锁
boolean failed = true;
try {int savedState = getState(); // 获取 volatile 的 state,独占模式下示意以后线程锁持有的全副锁
if (release(savedState)) { // 开释全副的锁
failed = false;
return savedState;
} else {throw new IllegalMonitorStateException(); // 未持有锁,报错
}
} finally {if (failed)
node.waitStatus = Node.CANCELLED;
}
}
3.1.3 isOnSyncQueue
判断节点是否在同步队列上。
java.util.concurrent.locks.AbstractQueuedSynchronizer#isOnSyncQueue
/**
* Returns true if a node, always one that was initially placed on
* a condition queue, is now waiting to reacquire on sync queue.
* @param node the node
* @return true if is reacquiring
*/
final boolean isOnSyncQueue(Node node) {if (node.waitStatus == Node.CONDITION || node.prev == null)
return false;
if (node.next != null) // If has successor, it must be on queue
return true;
return findNodeFromTail(node); // 从尾节点向前遍历查找
}
/**
* Returns true if node is on sync queue by searching backwards from tail.
* Called only when needed by isOnSyncQueue.
* @return true if present
*/
private boolean findNodeFromTail(Node node) {
Node t = tail;
for (;;) {if (t == node)
return true;
if (t == null)
return false;
t = t.prev;
}
}
1. 如果 waitStatus == CONDITION
阐明肯定是位于条件队列上。
从条件队列入队,结构节点的时候默认就为 CONDITION 状态。
将节点从条件队列转移到同步队列,首先会 CAS 设置 waitStatus 状态为 CONDITION,再执行入队操作。
2. node.prev == null
阐明肯定是位于条件队列上。
同步队列只有头节点合乎 node.prev == null
,然而同步队列的头节点是 dummy node,其 thread 为空。
也就是说,来调用 isOnSyncQueue 办法且合乎 node.prev == null
条件的节点,只可能是位于条件队列上的节点。
3. 如果 node.next != null
阐明肯定是处于同步队列上。
节点退出同步队列是个复合操作,最初一步是设置 node.next,当 node.next != null
阐明入队操作已执行实现。
4. 如果以上都无奈判断节点是否位于同步队列,则遍历链表查找节点。
存在 node.prev != null
然而节点还没有齐全入队胜利的状况,因为入队操作设置 prev -> tail -> next 是非原子操作。
所以须要从 tail 向前遍历,能力精确判断 node 是否位于同步队列上。
调用 findNodeFromTail 办法前,节点个别位于尾节点左近,不会遍历过多节点。
3.1.4 checkInterruptWhileWaiting
阻塞在 Condition#await 的线程被唤醒之后,调用 checkInterruptWhileWaiting 来查看是否是由线程中断唤醒的。
如果是由线程中断唤醒的,须要进一步判断如何解决中断:
- THROW_IE:throw new InterruptedException();
- REINTERRUPT:Thread.currentThread().interrupt();
java.util.concurrent.locks.AbstractQueuedSynchronizer.ConditionObject#checkInterruptWhileWaiting
/**
* Checks for interrupt, returning THROW_IE if interrupted
* before signalled, REINTERRUPT if after signalled, or
* 0 if not interrupted.
*/
private int checkInterruptWhileWaiting(Node node) {
// 校验以后线程是否被中断,并革除线程的中断状态
return Thread.interrupted() ?
(transferAfterCancelledWait(node) ? THROW_IE : REINTERRUPT) :
0; // 如果线程未被中断,返回 0
}
3.1.5 transferAfterCancelledWait
如果阻塞在 Condition#await 的线程是被中断唤醒的,执行 transferAfterCancelledWait 判断产生中断产生时节点所在的地位。
如果是位于条件队列,则将其增加到同步队列,返回 true;否则返回 false。
如何判断中断产生时节点所在的地位?
- 已知 Condition#signal 办法会批改状态(CONDITION -> 0),并操作节点从条件队列出队,从同步队列入队。
- 如果 Condition#await 执行 CAS 批改状态胜利(CONDITION -> 0),阐明线程中断产生时 Condition#signal 还没执行,此时节点是位于条件队列,须要将节点退出同步队列。
- 如果 Condition#await 执行 CAS 批改状态失败(CONDITION -> 0),阐明线程中断产生时 Condition#signal 曾经执行,以后线程须要自旋期待 Condition#signal 执行完。
java.util.concurrent.locks.AbstractQueuedSynchronizer#transferAfterCancelledWait
/**
* Transfers node, if necessary, to sync queue after a cancelled wait.
* Returns true if thread was cancelled before being signalled.
*
* @param node the node
* @return true if cancelled before the node was signalled
*/
final boolean transferAfterCancelledWait(Node node) {if (compareAndSetWaitStatus(node, Node.CONDITION, 0)) { // 通过 CAS 胜利与否来判断节点地位
enq(node); // 如果 CAS 胜利,阐明节点是位于条件队列,须要将它增加到同步队列
return true;
}
/*
* If we lost out to a signal(), then we can't proceed
* until it finishes its enq(). Cancelling during an
* incomplete transfer is both rare and transient, so just
* spin.
*/ // 条件队列上的节点失去告诉(Condition#signal)之后,会增加到同步队列中去。while (!isOnSyncQueue(node)) // 这里循环检测,直到确认节点曾经胜利增加到同步队列中。Thread.yield();
return false;
}
3.1.6 unlinkCancelledWaiters
在 Condition#await 办法中,当线程从阻塞中被线程中断唤醒后,判断节点是位于条件队列中,除了将节点退出同步队列之外,还须要将节点从条件队列中移除。
官网的阐明:
- 持有锁时才可调用该办法。
- 以后线程在 Condition#wait 中阻塞,在被 Condition#signal 唤醒之前,由线程中断或期待超时唤醒。此时须要调用该办法革除条件队列中的有效节点。
- 只管该办法会遍历整个队列,然而只有在 Condition#signal 没有执行之前产生中断或勾销才会调用。
- 该办法会遍历整个条件队列,一次性把所有有效节点都革除掉,当队列中短时间呈现大量有效节点时(cancellation storms)可防止屡次遍历队列。
java.util.concurrent.locks.AbstractQueuedSynchronizer.ConditionObject#unlinkCancelledWaiters
/**
* Unlinks cancelled waiter nodes from condition queue.
* Called only while holding lock. This is called when
* cancellation occurred during condition wait, and upon
* insertion of a new waiter when lastWaiter is seen to have
* been cancelled. This method is needed to avoid garbage
* retention in the absence of signals. So even though it may
* require a full traversal, it comes into play only when
* timeouts or cancellations occur in the absence of
* signals. It traverses all nodes rather than stopping at a
* particular target to unlink all pointers to garbage nodes
* without requiring many re-traversals during cancellation
* storms.
*/
private void unlinkCancelledWaiters() { // 革除条件队列中状态不为 CONDITION 的节点
Node t = firstWaiter; // 游标节点,记录以后遍历的节点
Node trail = null; // 游标节点,记录遍历过的最初一个无效节点(状态为 CONDITION)while (t != null) { // 从条件队列的头节点开始遍历(上面正文用 next 代表下一个节点)Node next = t.nextWaiter;
if (t.waitStatus != Node.CONDITION) { // 以后 t 为有效节点
t.nextWaiter = null;
if (trail == null) // 首次遍历到 t 为无效节点时,才会初始化 trail
firstWaiter = next; // 设置 t.next 为新的头节点(下一次循环校验 t.next:若 t.next 有效,则把 t.next.next 设为新的头节点)else
trail.nextWaiter = next; // 设置 trail.next 为 t.next(把 t 出队,下一次循环校验 t.next:若 t.next 有效,则把 t.next.next 设为 trail.next)if (next == null)
lastWaiter = trail; // 设置 trail 为新的尾节点
}
else // 以后 t 为无效节点
trail = t;
t = next; // 持续遍历 t.next
}
}
3.1.7 reportInterruptAfterWait
Condition#await 执行到最初,从阻塞中被唤醒且从新获得锁,判断 interruptMode != 0,即 Condition#await 整个过程中产生过中断,须要对中断进行对立解决。
具体见设置 interruptMode 的代码:checkInterruptWhileWaiting
- 如果在失去告诉之前被中断(在条件队列中),返回 THROW_IE
- 如果在失去告诉之后被中断(在同步队列中),返回 REINTERRUPT
java.util.concurrent.locks.AbstractQueuedSynchronizer.ConditionObject#reportInterruptAfterWait
/**
* Throws InterruptedException, reinterrupts current thread, or
* does nothing, depending on mode.
*/
private void reportInterruptAfterWait(int interruptMode)
throws InterruptedException {if (interruptMode == THROW_IE)
throw new InterruptedException();
else if (interruptMode == REINTERRUPT)
selfInterrupt();}
java.util.concurrent.locks.AbstractQueuedSynchronizer#selfInterrupt
/**
* Convenience method to interrupt current thread.
*/
static void selfInterrupt() {Thread.currentThread().interrupt();}
3.2 Condition#awaitNanos
在 Condition 条件上阻塞,具备超时工夫。
- Condition#await:Block until signalled or interrupted.
- Condition#awaitNanos:Block until signalled, interrupted, or timed out.
java.util.concurrent.locks.AbstractQueuedSynchronizer.ConditionObject#awaitNanos
/**
* Implements timed condition wait.
* <ol>
* <li> If current thread is interrupted, throw InterruptedException.
* <li> Save lock state returned by {@link #getState}.
* <li> Invoke {@link #release} with saved state as argument,
* throwing IllegalMonitorStateException if it fails.
* <li> Block until signalled, interrupted, or timed out.
* <li> Reacquire by invoking specialized version of
* {@link #acquire} with saved state as argument.
* <li> If interrupted while blocked in step 4, throw InterruptedException.
* </ol>
*/
public final long awaitNanos(long nanosTimeout)
throws InterruptedException {if (Thread.interrupted())
throw new InterruptedException();
Node node = addConditionWaiter();
int savedState = fullyRelease(node);
final long deadline = System.nanoTime() + nanosTimeout; // 期待截止的工夫戳
int interruptMode = 0;
while (!isOnSyncQueue(node)) {if (nanosTimeout <= 0L) { // 已超时,查看节点所在位置,判断是否把节点退出同步队列
transferAfterCancelledWait(node);
break;
}
if (nanosTimeout >= spinForTimeoutThreshold) // 大于工夫阈值,进行阻塞;小于工夫阈值,进行自旋
LockSupport.parkNanos(this, nanosTimeout);
if ((interruptMode = checkInterruptWhileWaiting(node)) != 0) // 从阻塞中唤醒后,查看是否产生中断,如有中断则完结自旋
break;
nanosTimeout = deadline - System.nanoTime(); // 残余等待时间}
if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
interruptMode = REINTERRUPT;
if (node.nextWaiter != null)
unlinkCancelledWaiters();
if (interruptMode != 0)
reportInterruptAfterWait(interruptMode);
return deadline - System.nanoTime(); // 返回残余的阻塞工夫}
java.util.concurrent.locks.AbstractQueuedSynchronizer#spinForTimeoutThreshold
/**
* The number of nanoseconds for which it is faster to spin
* rather than to use timed park. A rough estimate suffices
* to improve responsiveness with very short timeouts.
*/
static final long spinForTimeoutThreshold = 1000L;
3.3 Condition#awaitUninterruptibly
在 Condition 条件上阻塞,只能被 Condition#signal 唤醒。
- Condition#await:Block until signalled or interrupted.
- Condition#awaitNanos:Block until signalled, interrupted, or timed out.
- Condition#awaitUninterruptibly:Block until signalled.
java.util.concurrent.locks.AbstractQueuedSynchronizer.ConditionObject#awaitUninterruptibly
/**
* Implements uninterruptible condition wait.
* <ol>
* <li> Save lock state returned by {@link #getState}.
* <li> Invoke {@link #release} with saved state as argument,
* throwing IllegalMonitorStateException if it fails.
* <li> Block until signalled.
* <li> Reacquire by invoking specialized version of
* {@link #acquire} with saved state as argument.
* </ol>
*/
public final void awaitUninterruptibly() {Node node = addConditionWaiter();
int savedState = fullyRelease(node);
boolean interrupted = false;
while (!isOnSyncQueue(node)) {LockSupport.park(this);
if (Thread.interrupted())
interrupted = true;
}
if (acquireQueued(node, savedState) || interrupted)
selfInterrupt();}
4. Condition 告诉办法
4.1 Condition#signal
唤醒在 Condition#await 上期待最久的线程。
把条件队列的头节点出队,把它退出同步队列,并唤醒节点中的线程。
被唤醒的线程从 Condition#await 中醒来后,执行 AbstractQueuedSynchronizer#acquireQueued 期待再次获取锁。
java.util.concurrent.locks.AbstractQueuedSynchronizer.ConditionObject#signal
/**
* Moves the longest-waiting thread, if one exists, from the
* wait queue for this condition to the wait queue for the
* owning lock.
*
* @throws IllegalMonitorStateException if {@link #isHeldExclusively}
* returns {@code false}
*/
public final void signal() {if (!isHeldExclusively()) // 未持有独占锁,报错
throw new IllegalMonitorStateException();
Node first = firstWaiter;
if (first != null)
doSignal(first); // 唤醒队首节点(等待时间最长)}
4.1.1 doSignal
- 找到适合的可唤醒的节点,个别是条件队列的头节点,将它从条件队列出队。
- 如果头节点是有效节点,则出队直到找到无效节点。
java.util.concurrent.locks.AbstractQueuedSynchronizer.ConditionObject#doSignal
/**
* Removes and transfers nodes until hit non-cancelled one or
* null. Split out from signal in part to encourage compilers
* to inline the case of no waiters.
* @param first (non-null) the first node on condition queue
*/
private void doSignal(Node first) { // 把条件队列的头节点转移到同步队列
do {if ( (firstWaiter = first.nextWaiter) == null) // 以后节点的后继节点作为新的头节点(出队),若为空,阐明队列为空
lastWaiter = null;
first.nextWaiter = null;
} while (!transferForSignal(first) && // 把以后节点转移到同步队列(入队),并唤醒节点上的线程(阐明条件队列的头节点不是 dummy node)(first = firstWaiter) != null); // 转移失败,取最新的 firstWaiter,若不为空则重试,若为空,阐明队列为空
}
4.1.2 transferForSignal
- 批改节点状态:CONDITION -> 0
- 退出到同步队列
- 唤醒节点
java.util.concurrent.locks.AbstractQueuedSynchronizer#transferForSignal
/**
* Transfers a node from a condition queue onto sync queue. // 将一个节点从条件队列转移到同步队列
* Returns true if successful.
* @param node the node
* @return true if successfully transferred (else the node was
* cancelled before signal)
*/
final boolean transferForSignal(Node node) {
/*
* If cannot change waitStatus, the node has been cancelled. // 条件队列上的节点状态不为 CONDITION,阐明是已勾销
*/
if (!compareAndSetWaitStatus(node, Node.CONDITION, 0))
return false;
/*
* Splice onto queue and try to set waitStatus of predecessor to
* indicate that thread is (probably) waiting. If cancelled or
* attempt to set waitStatus fails, wake up to resync (in which
* case the waitStatus can be transiently and harmlessly wrong).
*/
Node p = enq(node); // 增加到同步队列,返回上一个节点
int ws = p.waitStatus;
if (ws > 0 || !compareAndSetWaitStatus(p, ws, Node.SIGNAL))
LockSupport.unpark(node.thread); // 查看上一个节点,发现不具备唤醒以后节点条件,则立刻唤醒以后节点
return true; // 补充:node.thread 从 Condition#await 之中被唤醒,后续执行 acquireQueued 尝试获取锁
}
4.2 Condition#signalAll
遍历条件队列,顺次唤醒所有节点。
所有节点都会迁徙到同步队列期待获取锁。
java.util.concurrent.locks.AbstractQueuedSynchronizer.ConditionObject#signalAll
/**
* Moves all threads from the wait queue for this condition to
* the wait queue for the owning lock.
*
* @throws IllegalMonitorStateException if {@link #isHeldExclusively}
* returns {@code false}
*/
public final void signalAll() {if (!isHeldExclusively())
throw new IllegalMonitorStateException();
Node first = firstWaiter;
if (first != null)
doSignalAll(first);
}
java.util.concurrent.locks.AbstractQueuedSynchronizer.ConditionObject#doSignalAll
/**
* Removes and transfers all nodes.
* @param first (non-null) the first node on condition queue
*/
private void doSignalAll(Node first) {
lastWaiter = firstWaiter = null;
do {
Node next = first.nextWaiter;
first.nextWaiter = null;
transferForSignal(first);
first = next;
} while (first != null);
}
相干浏览:
浏览 JDK 8 源码:AQS 中的独占模式
浏览 JDK 8 源码:AQS 中的共享模式
浏览 JDK 8 源码:AQS 对 Condition 的实现
作者:Sumkor