并发番@ConditionObject一文通
Java 1.8版本 并发
1.Condition接口
- Condition接口意义在于提供一种针对使用条件状态(队列或变量)的线程进行阻塞和唤醒的机制 ：
- 阻塞： 阻塞线程进入等待状态同时释放关联锁，直到被其他线程将条件状态设置为true为止
- 唤醒： 唤醒等待在条件队列中的线程，同时提供对唤醒全部的支持
- 锁关联： 值得注意的是，由于多线程下该状态是共享的，因此通常会通过于锁关联保证其原子性
- 解除等待： 当线程解除等待状态(被唤醒、中断、超时等)后仍需重新竞争锁，获取锁后才能够从暂停位置开始继续往后执行
/*
* Conditions (also known as `condition queues` or `condition variables`)
* provide a means for one thread to suspend execution to wait
* until notified by another thread that some state condition may now be true.
*
* Conditions(如条件队列或条件变量)的作用如下：
* 暂停线程并进入等待状态，直到被其他线程将条件状态设置为true为止
* 值得注意的是：由于多线程下该状态是共享的，因此通常会通过于锁关联保证其原子性
* 如Lock#newCondition newCondition()方法
*/
public interface Condition {
/**
* Causes the current thread to wait until it is signalled or {Thread#interrupt interrupted}
* 线程等待直到被唤醒或被中断
* 阻塞方法的实现有几个准则：
* 1.当前线程持有的锁(关联该条件变量)将被释放
* 2.当线程解除等待状态后仍需重新竞争锁，获取锁后才能够从当前位置开始继续往后执行
*/
void await() throws InterruptedException;
/**
* Causes the current thread to wait until it is signalled.
* 线程等待直到被唤醒
*/
void awaitUninterruptibly();
/**
* Causes the current thread to wait until it is signalled or interrupted,
* or the specified waiting time elapses.
* 线程等待直到被唤醒或被中断或超时
*/
long awaitNanos(long nanosTimeout) throws InterruptedException;
/**
* Causes the current thread to wait until it is signalled or interrupted,
* or the specified waiting time elapses. This method is behaviorally
* equivalent to: {@code awaitNanos(unit.toNanos(time)) > 0}
* 线程等待直到被唤醒或被中断或超时
* 该方法等同于 awaitNanos(unit.toNanos(time)) > 0
*/
boolean await(long time, TimeUnit unit) throws InterruptedException;
/**
* Causes the current thread to wait until it is signalled or interrupted,
* or the specified deadline elapses.
* 线程等待直到被唤醒或被中断或超时
*/
boolean awaitUntil(Date deadline) throws InterruptedException;
/**
* Wakes up one waiting thread.
* 唤醒在条件队列中等待的一个线程
* 注意：线程被唤醒后仍需重新竞争锁，获取锁后才能够从当前位置开始继续往后执行
*/
void signal();
/**
* Wakes up all waiting threads.
* 唤醒在条件队列中等待的所有线程
*/
void signalAll();
}
2.ConditionObject综述
- ConditionObject包括如下方面：
- 定位：
ConditionObject是AQS的内部类，其通过实现Condition接口提供对管程形式的条件的支持
- 作用：
ConditionObject在AQS中作为对Lock的实现支持
- 使用： 当条件不满足时线程入队，当条件满足时出队并重新尝试获取锁，获取成功后从暂停位置开始继续往后执行
3.ConditionObject实现原理
- ConditionObject的实现有几个注意事项：
- 1.内部会维护一个条件等待同步队列，根据FIFO原则执行入队出队操作
- 2.通过
firstWaiter维护头节点，lastWaiter维护尾节点
- 3.节点通过
nextWaiter记录后继条件节点形成链表结构，遍历时从头节点开始沿着nextWaiter顺序遍历
- 4.条件队列中节点状态
waitStatus只能为0或Node.CONDITION
- 5.使用条件队列的前提是线程需要持有同步锁，且只支持独占模式
- 6.当节点在条件队列被唤醒(因signal|timeout|interrupt)后，需要进行节点转移，即由条件节点转变为同步节点
4.ConditionObject组成
4.1 类定义
public class ConditionObject implements Condition, java.io.Serializable
4.2 构造器
public ConditionObject() { }
4.3 重要变量
/** 条件等待队列首节点 */
private transient Node firstWaiter;
/** 条件等待队列尾节点 */
private transient Node lastWaiter;
/** 退出时重新中断*/
private static final int REINTERRUPT = 1;
/** 退出时直接抛出异常 */
private static final int THROW_IE = -1;
/** 独占模式时才能使用条件队列 ，用于链接下一个等待节点 */
Node nextWaiter;
5.条件节点阻塞
5.1 不响应中断阻塞
- 条件节点阻塞的一般流程：
- 1.入队： 根据FIFO原则，新节点会被封装成Node并被加入到条件队列队尾
- 2.释放： 为不影响其他线程，当前已持有锁的线程需要先释放所有锁，让出锁资源
- 3.阻塞： 在条件队列中的节点线程需要被阻塞，直到条件满足后重试获取同步锁
- 4.重试： 当条件满足后需要重试获取同步锁，获取成功后才能继续从暂停位置继续向后执行
补充：条件满足指的是线程被其他线程唤醒、或超时、或中断后且位于同步队列中
public final void awaitUninterruptibly() {
//1.新节点入条件队列
Node node = addConditionWaiter();
//2.当前线程已持有锁，但由于要被阻塞，为不影响其他线程，需要先释放锁
int savedState = fullyRelease(node);
//3.阻塞在条件队列中的不满足条件的节点线程
boolean interrupted = false;
while (!isOnSyncQueue(node)) {
LockSupport.park(this);
//由于不响应中断，因此只是记录是否中断，此时会清除中断标识
if (Thread.interrupted())
interrupted = true;
}
/**
* 4.被唤醒需要重新尝试获取锁，获取锁成功后才能继续往后执行
* 若期间又被中断后，需要再次设置已被清除的中断标识
*/
if (acquireQueued(node, savedState) || interrupted)
selfInterrupt();
}
小问：为神马需要循环判断isOnSyncQueue？ 即while (!isOnSyncQueue(node)) ？
友情小提示：读者可以回顾一下同步队列获取锁的过程
小答：循环只有一个目的，就是确保节点已经脱离条件队列且进入同步队列，这样才有资格重新获取同步锁
5.2 响应中断阻塞
public final void await() throws InterruptedException {
//响应中断，直接抛异常，没必要往下走了
if (Thread.interrupted())
throw new InterruptedException();
//新节点入条件队列
Node node = addConditionWaiter();
//当前线程已持有锁，但由于要被阻塞，为不影响其他线程，需要先释放锁
int savedState = fullyRelease(node);
//只阻塞在条件队列中的节点线程，同步节点才能竞争同步锁
int interruptMode = 0;
while (!isOnSyncQueue(node)) {
LockSupport.park(this);
/**
* 检测中断，一旦发生中断
* 1.将条件队列中因中断而唤醒的节点进行转移(注意此处是中断)
* 2.退出循环 -> 接下来会在循环外进行中断处理
* 注意：之所以安心退出是因为会通过执行transferAfterCancelledWait进行节点转移
* 这样随后就能安心执行acquireQueued同步队列入队操作了
*/
if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
break;
}
/**
* 重新尝试获取同步锁，获取成功后且被中断，当中断模式为抛出异常时，需要设置为重新中断
* 补充：acquireQueued会返回获取锁过程中线程是否有过中断，true则说明发生过中断
*/
if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
interruptMode = REINTERRUPT;
/**
* 若当前节点存在后继节点时，需要执行出队操作
* 补充：acquireQueued会返回获取锁过程中线程是否有过中断，true则说明发生过中断
*/
if (node.nextWaiter != null) // clean up if cancelled
unlinkCancelledWaiters();
//interruptMode != 0 说明是需要进行中断处理的
if (interruptMode != 0)
//执行中断处理
reportInterruptAfterWait(interruptMode);
}
/**
* 中断处理：
* 1.中断模式为THROW_IE：向上抛出异常
* 2.中断模式为REINTERRUPT：重新设置中断状态
*/
private void reportInterruptAfterWait(int interruptMode)
throws InterruptedException {
if (interruptMode == THROW_IE)
throw new InterruptedException();
else if (interruptMode == REINTERRUPT)
selfInterrupt();
}
5.3 响应中断和超时阻塞-纳秒可选
/**
* Implements timed condition wait.
* 响应中断和超时阻塞
* @return long 剩余超时时间 <0 说明已超时
*/
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)) {
/**
* 将条件队列中因超时而唤醒的节点进行转移(注意此处是超时)
* 值得注意的是：剩余超时时间允许为0和负数
*/
if (nanosTimeout <= 0L) {
transferAfterCancelledWait(node);
break;
}
//为了提高效率，超过阈值才执行阻塞，否则接着自旋
if (nanosTimeout >= spinForTimeoutThreshold)
//若超过nanosTimeout时长，会自动解除阻塞唤醒线程
LockSupport.parkNanos(this, nanosTimeout);
/**
* 检测中断，一旦发生中断
* 1.将条件队列中因中断而唤醒的节点进行转移(注意此处是中断)
* 2.退出循环 -> 接下来会在循环外进行中断处理
* 注意：之所以安心退出是因为会通过执行transferAfterCancelledWait进行节点转移
* 这样随后就能安心执行acquireQueued同步队列入队操作了
*/
if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
break;
//剩余超时时间
nanosTimeout = deadline - System.nanoTime();
}
/**
* 重新尝试获取同步锁，获取成功后且被中断，当中断模式为抛出异常时，需要设置为重新中断
* 补充：acquireQueued会返回获取锁过程中线程是否有过中断，true则说明发生过中断
*/
if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
interruptMode = REINTERRUPT;
/**
* 若当前节点存在后继节点时，需要执行出队操作
* 补充：acquireQueued会返回获取锁过程中线程是否有过中断，true则说明发生过中断
*/
if (node.nextWaiter != null)
unlinkCancelledWaiters();
//interruptMode != 0 说明是需要进行中断处理的
if (interruptMode != 0)
//执行中断处理
reportInterruptAfterWait(interruptMode);
//返回已花费时长
return deadline - System.nanoTime();
}
5.4 响应中断和超时阻塞-纳秒日期单位可选
/**
* Implements timed condition wait.
* 响应中断和超时阻塞-纳秒日期单位可选
* @return boolean 超时是否发生在被唤醒之前
*/
public final boolean await(long time, TimeUnit unit)
throws InterruptedException {
//注意是纳秒
long nanosTimeout = unit.toNanos(time);
//响应中断，直接抛异常，没必要往下走了
if (Thread.interrupted())
throw new InterruptedException();
//新节点入条件队列
Node node = addConditionWaiter();
//当前线程已持有锁，但由于要被阻塞，为不影响其他线程，需要先释放同步锁
int savedState = fullyRelease(node);
//截止时长
final long deadline = System.nanoTime() + nanosTimeout;
//只阻塞在条件队列中的节点线程，同步节点才能竞争同步锁
boolean timedout = false;
int interruptMode = 0;
while (!isOnSyncQueue(node)) {
/**
* 将条件队列中因超时而唤醒的节点进行转移(注意此处是超时)
* 值得注意的是：剩余超时时间允许为0和负数
*/
if (nanosTimeout <= 0L) {
timedout = transferAfterCancelledWait(node);
break;
}
//为了提高效率，超过阈值才执行阻塞，否则接着自旋
if (nanosTimeout >= spinForTimeoutThreshold)
//若超过nanosTimeout时长，会自动解除阻塞唤醒线程
LockSupport.parkNanos(this, nanosTimeout);
/**
* 检测中断，一旦发生中断
* 1.将条件队列中因中断而唤醒的节点进行转移(注意此处是中断)
* 2.退出循环 -> 接下来会在循环外进行中断处理
* 注意：之所以安心退出是因为会通过执行transferAfterCancelledWait进行节点转移
* 这样随后就能安心执行acquireQueued同步队列入队操作了
*/
if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
break;
//剩余超时时间
nanosTimeout = deadline - System.nanoTime();
}
/**
* 重新尝试获取同步锁，获取成功后且被中断，当中断模式为抛出异常时，需要设置为重新中断
* 补充：acquireQueued会返回获取锁过程中线程是否有过中断，true则说明发生过中断
*/
if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
interruptMode = REINTERRUPT;
/**
* 若当前节点存在后继节点时，需要执行出队操作
* 补充：acquireQueued会返回获取锁过程中线程是否有过中断，true则说明发生过中断
*/
if (node.nextWaiter != null)
unlinkCancelledWaiters();
//interruptMode != 0 说明是需要进行中断处理的
if (interruptMode != 0)
//执行中断处理
reportInterruptAfterWait(interruptMode);
return !timedout;
}
5.5 响应中断和超时阻塞-毫秒日期可选
/**
* Implements absolute timed condition wait.
* 响应中断和超时阻塞-毫秒日期可选
* @return boolean 超时是否发生在被唤醒之前
*/
public final boolean awaitUntil(Date deadline)
throws InterruptedException {
//注意：与awaitNano区别的是这里用的是毫秒
long abstime = deadline.getTime();
//响应中断，直接抛异常，没必要往下走了
if (Thread.interrupted())
throw new InterruptedException();
//新节点入条件队列
Node node = addConditionWaiter();
//当前线程已持有锁，但由于要被阻塞，为不影响其他线程，需要先释放同步锁
int savedState = fullyRelease(node);
//记录节点是否超时
boolean timedout = false;
//只阻塞在条件队列中的节点线程，同步节点才能竞争同步锁
int interruptMode = 0;
while (!isOnSyncQueue(node)) {
//毫秒超时，将条件队列中因超时而唤醒的节点进行转移(注意此处是超时)
if (System.currentTimeMillis() > abstime) {
/**
* 记录节点是否超时
* 注意：当取消发生在节点被唤醒之前才返回true
*/
timedout = transferAfterCancelledWait(node);
//转换一定会成功，因此安心退出即可
break;
}
//若超过abstime时长，会自动解除阻塞唤醒线程
LockSupport.parkUntil(this, abstime);
/**
* 检测中断，一旦发生中断
* 1.将条件队列中因中断而唤醒的节点进行转移(注意此处是中断)
* 2.退出循环 -> 接下来会在循环外进行中断处理
* 注意：之所以安心退出是因为会通过执行transferAfterCancelledWait进行节点转移
* 这样随后就能安心执行acquireQueued同步队列入队操作了
*/
if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
break;
}
/**
* 重新尝试获取同步锁，获取成功后且被中断，当中断模式为抛出异常时，需要设置为重新中断
* 补充：acquireQueued会返回获取锁过程中线程是否有过中断，true则说明发生过中断
*/
if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
interruptMode = REINTERRUPT;
/**
* 若当前节点存在后继节点时，需要执行出队操作
* 补充：acquireQueued会返回获取锁过程中线程是否有过中断，true则说明发生过中断
*/
if (node.nextWaiter != null)
unlinkCancelledWaiters();
//interruptMode != 0 说明是需要进行中断处理的
if (interruptMode != 0)
//执行中断处理
reportInterruptAfterWait(interruptMode);
return !timedout;
}
6.条件节点唤醒
- 唤醒操作主要干了三个事情：
- 1.清除节点： 从条件队列中移除该节点
- 2.节点转移： 将条件节点转换为同步节点，即从条件队列转移到同步队列
- 3.唤醒节点： 将转移成功的节点重新唤醒
6.1 唤醒单个
唤醒单个的实质：根据FIFO原则唤醒first，即条件队列头节点
/**
* Moves the longest-waiting thread, if one exists, from the
* wait queue for this condition to the wait queue for the
* owning lock.
*
* 从条件队列中唤醒一个节点
* 原则:将条件队列中已存在的等待时间最长的线程转移到等待队列中，即头节点
*/
public final void signal() {
//条件队列只适用于独占模式且只能由持有锁的线程执行唤醒操作
if (!isHeldExclusively())
throw new IllegalMonitorStateException();
//先进先出原则
Node first = firstWaiter;
if (first != null)
doSignal(first);
}
/**
* Removes and transfers nodes until hit non-cancelled one or null.
* @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) && (first = firstWaiter) != null);
}
6.2 唤醒全部
唤醒全部的实质：沿着nextWaiter顺序遍历依次唤醒
/**
* Moves all threads from the wait queue for this condition to
* the wait queue for the owning lock.
*
* 唤醒条件队列中的全部节点
*/
public final void signalAll() {
if (!isHeldExclusively())
throw new IllegalMonitorStateException();
Node first = firstWaiter;
if (first != null)
//跟signal的区别就是多了个All...
doSignalAll(first);
}
/**
* Removes and transfers all nodes.
*
* 全部唤醒的实质：
* 沿着nextWaiter顺序遍历依次转移并唤醒
*/
private void doSignalAll(Node first) {
//1.注意要清空条件队列
lastWaiter = firstWaiter = null;
//2.沿着nextWaiter顺序遍历依次唤醒
do {
Node next = first.nextWaiter;
first.nextWaiter = null;
transferForSignal(first);
//3.其实质就是沿着nextWaiter顺序遍历
first = next;
} while (first != null);
}
7.条件节点转移
- 转移操作指的是节点由条件节点转换为同步节点，主要进行了如下三步进行转移：
- 1.更新节点状态： 根据同步队列入队原则，新节点初始状态必须为0
- 2.同步队列入队： 当前节点肯定能入队成功，同时返回前驱节点
- 3.唤醒当前线程： 若前驱节点是CANCELLED或SIGNAL时，需要唤醒当前线程
7.1 因正常唤醒转移
/**
* Transfers a node from a condition queue onto sync queue.
* Returns true if successful.
*
* 将节点从条件队列转换到同步队列中并唤醒线程
* 1.在正常调用signalXXX()方法时才会调用该方法
* 2.若因为超时或中断进行转移，不会调用该方法，但这两种情况的转移都会置为0
* 3.注意：在调用该方法之前都会执行first.nextWaiter = null，即从等待队列中移除当前头节点
*
* @param node the node 根据FIFO原则，通常为first节点
* @return true if successfully transferred (else the node was
* cancelled before signal) 转换成功或节点在唤醒前被取消 才返回true
*/
final boolean transferForSignal(Node node) {
/**
* 1.CAS更新节点状态为0，一旦失败立即返回false
* 注意：必须将节点状态更新为0，因为同步队列入队时新节点必须为0，
* 否则就不符合同步队列入队原则，因此一旦失败立即返回
* 补充：CAS失败的原因在于其他线程已经执行唤醒操作将该节点变更为0，因此其实无需再次enq了
*/
if (!compareAndSetWaitStatus(node, Node.CONDITION, 0))
return false;
//2.进入同步队列，注意enq方法返回的是前驱节点
Node p = enq(node);
/**
* 3.唤醒节点线程
* ws > 0：
* 说明前驱节点被取消(CANCELLED)，因此需要唤醒当前节点线程
* !compareAndSetWaitStatus(p, ws, Node.SIGNAL)：
* 说明前驱节点已经是SIGNAL或CANCELLED，因此也要唤醒当前节点线程
* 补充：因为enq保证一定入队成功，因此实质是唤醒在同步队列中的节点
* 结合awaitXXX()，线程会从park之后继续往后执行
*/
int ws = p.waitStatus.
if (ws > 0 || !compareAndSetWaitStatus(p, ws, Node.SIGNAL))
LockSupport.unpark(node.thread);
return true;
}
小问：读者还记得enq方法都做了什么吗?
友情小提示：读者可以回顾一下并发番@AbstractQueuedSynchronizer一文通
- 小答：针对enq方法，笔者简单回顾一下作用，帮助读者理解一下：
- 1.初始化时对head和tail进行赋值
- 2.当前节点进入同步对了并作为新的tail
- 3.入队一定可以成功因为自旋
- 4.注意enq返回的是前驱节点
7.2 因中断或超时唤醒转移
/**
* Transfers node, if necessary, to sync queue after a cancelled wait.
* Returns true if thread was cancelled before being signalled.
*
* 将条件队列中因中断或超时而唤醒的节点进行转移
* 取消发生在被唤醒之前返回true
* 两种情况需要调用该方法：
* 1.中断：checkInterruptWhileWaiting() -> 该方法会被awaitXXX()调用
* 2.超时：带超时的awaitXXX()方法
*/
final boolean transferAfterCancelledWait(Node node) {
//Node.CONDITION状态节点只用于条件队列，因此需要设置为0才能进入同步队列
if (compareAndSetWaitStatus(node, Node.CONDITION, 0)) {
//当CAS变更waitStatus为0时，说明节点已跟条件队列无关，随后进入同步队列即可
enq(node);
//由于enq方法能够保证进入同步队列成功，因此当enq执行完毕，可以放心的返回true
return true;
}
//若CAS失败且节点还不在同步队列中，线程需要先释放资源，提高效率
while (!isOnSyncQueue(node))
Thread.yield();
return false;
}
小问：为什么需要执行Thread.yield()?
友情小提示：读者可以从效率优化角度考虑
- 小答：对于这个问题，笔者的考虑如下：
- 1.若CAS变更为0失败，说明已被其他线程执行唤醒转换并变更为0
- 2.但由于enq操作可能还在进行中，因此此时该节点可能还没真正入队，因此需要循环检测是否已入队
- 3.由于入队操作已经在执行中，因此无需重复执行enq操作，可以先释放资源，并通过isOnSyncQueue退出循环即可，优化效率
8.条件节点队列操作
8.1 条件节点入队
- 新节点入队遵循FIFO原则，主要会做如下操作：
- 1.清洗： 若尾节点非
CONDITION状态，需要清除所有非CONDITION状态节点并重设头尾节点
- 2.封装： 封装当前线程为Node，同时初始化节点状态为
CONDITION
- 3.入队： 队列为空时，头尾节点指向同一个元素；非空时通过
nextWaiter形成链表
/**
* Adds a new waiter to wait queue.
*
* 新增条件等待队列队尾节点 - FIFO
* 补充：由于条件队列只适用于独占模式，因此该方法不会有并发问题
* @return its new wait node 返回新节点
*/
private Node addConditionWaiter() {
//FIFO原则：新入队元素需队尾插入
Node t = lastWaiter;
//1.若尾节点非Condition状态，需要清除所有非CONDITION状态节点并重设头尾节点
if (t != null && t.waitStatus != Node.CONDITION) {
/**
* 删除条件等待队列中的所有非CONDITION状态节点
* 补充：由于在条件队列中节点状态只能是CONDITION或0(signal|timeout|interrupt)
* 因此该方法实质就清除空节点或状态为0节点
*/
unlinkCancelledWaiters();
//上个方法执行后会使得lastWaiter肯定为非取消状态节点(只可能为空或CONDITION状态)
t = lastWaiter;
}
//2.封装当前线程为Node，同时初始化节点状态为CONDITION
Node node = new Node(Thread.currentThread(), Node.CONDITION);
//3.队尾元素为空，正说明条件队列为空
if (t == null)
firstWaiter = node;
else
//4.新元素入队需队尾插入
t.nextWaiter = node;
//5.这里需要注意的是：队列为空时，头尾节点是指向同一个元素的；非空时就会形成链表
lastWaiter = node;
return node;
}
小问：何时出现t != null && t.waitStatus != Node.CONDITION？
友情小提示:读者可以考虑一下条件节点状态的变更时机
- 小答：尾节点的状态不为Node.CONDITION，那只可能为0，这意味着节点需要转移，那么节点状态变更时机都有哪些呢？
- 1.当因中断或超时被唤醒后会通过调用
transferAfterCancelledWait将节点状态CAS为0
- 2.当被正常唤醒后会通过调用
transferForSignal将节点状态CAS为0
- 分析：但问题是正常唤醒后会先执行
first.nextWaiter = null，因此此时尾节点应为空
- 结论：排除这种情况后可知，只有第一种情况，即因中断或超时被唤醒后才会出现这种情况
那么问题来了，什么时候节点才真正出队呢？聪明的读者可以先思考一下~
8.2 条件节点出队
- 条件节点的出队时机：
- 1.新节点入队： 通过判断
t.waitStatus != Node.CONDITION为true时执行unlinkCancelledWaiters()
- 2.节点重新尝试获取同步锁后： 通过判断
node.nextWaiter != null为true时执行unlinkCancelledWaiters()
- 3.节点被正常唤醒后： 通过调用
signal()方法并执行first.nextWaiter = null
补充：3与1,2的区别在于前者只是清除头节点，后者是遍历清除所有非CONDITION状态节点
注意：无论入队还是出队，前提都是线程已经持有同步锁
/**
* Unlinks cancelled waiter nodes from condition queue.
*
* 移除条件队列中的所有非CONDITION状态节点
* 两种情况会触发该方法：
* 1.新节点加入条件队列时 -> addConditionWaiter()
* 2.节点被唤醒之后 -> awaitXXX()
* 补充一点：注意不是在signal()方法中执行的(因为后者只有转移和唤醒操作，前者才有获取锁操作)
* 注意：条件队列中的节点只有CONDITION和0两种状态
*/
private void unlinkCancelledWaiters() {
Node t = firstWaiter;
//临时节点，主要用于在遍历时记录上一个非CONDITION节点(因为要跳过所有非CONDITION节点)
Node trail = null;
//从前往后顺序遍历条件队列，剔除全部非CONDITION状态节点
while (t != null) {
//下一个节点，注意next可能为空
Node next = t.nextWaiter;
/**
* 非CONDITION状态(即0)，需要执行移除操作
* 强调：在条件队列中节点的waitStatus，只可能是CONDITION或是0(signal|timeout|interrupt)
*/
if (t.waitStatus != Node.CONDITION) {
/**
* 移除后继节点 等同于 将当前节点从队列中移除
* 同时由于不再有引用，会help GC
* 注意:GC同时会考虑firstWaiter和lastWaiter的引用情况
* 即若当前线程无用，上述变量最终也会移除对该节点的引用
*/
t.nextWaiter = null;
/**
* 若之前没有非CONDITION状态节点，就先让next当一下头头
* 注意：该方法执行完毕后，firstWaiter只能为空或CONDITION
*/
if (trail == null)
firstWaiter = next;
else
/**
* 一旦当前节点非CONDITION状态，那么需要先将它的后继节点与上一个非取消节点建立起联系
* 即使后继节点是非CONDITION状态也没事，因为在下次遍历时会重新建立联系的
* 说白了，其本质就是删除t
*/
trail.nextWaiter = next;
/**
* 最后一个非CONDITION状态节点即是条件队列的尾节点
* 注意：该方法执行完毕后，lastWaiter最终只能为空或CONDITION
*/
if (next == null)
lastWaiter = trail;
}
else
//CONDITION状态，就记录一下以作为下次遍历时的上一个非CONDITION节点
trail = t;
//开启下一次循环
t = next;
}
}
小问：为神马调用unlinkCancelledWaiters后firstWaiter只能为空或CONDITION？
友情小提示:一时间想不清楚的话可以使用分类讨论法
小答：头节点非空时，有且只有条件队列中全部都是非CONDITION状态的节点时，新的头节点才能为空，原因在于firstWaiter = next;的前提是无可用的CONDITION状态节点，而trail只有在有CONDITION状态节点时才会被赋值更新
9.重要方法
9.1 释放同步锁
/**
* Invokes release with current state value; returns saved state.
* Cancels node and throws exception on failure.
*
* 释放同步状态并返回原状态
* 当释放失败时节点会被取消同时抛出IllegalMonitorStateException异常
*/
final int fullyRelease(Node node) {
boolean failed = true;
try {
//获取当前线程持有锁的同步状态 -- 支持可重入
int savedState = getState();
/**
* 由于该方法只用于独占模式，因此使用的是独占独有的release方法
* 关于release方法请参见笔者的并发番@AbstractQueuedSynchronizer一文通
* 作用是更新state状态(为0)同时唤醒后继节点(如果存在的话)
*/
if (release(savedState)) {
failed = false;
return savedState;
} else {
//一旦释放失败，直接抛出异常 -- 干脆的很
throw new IllegalMonitorStateException();
}
} finally {
/**
* 释放失败的补救措施：
* 由于实际上节点已完成使命，节点状态需要变成取消状态以用于跳过和回收
* 注意：此时节点还是同步节点，因此需要设置为CANCELLED
*/
if (failed)
node.waitStatus = Node.CANCELLED;
}
}
9.2 检测中断
/**
* Checks for interrupt, returning THROW_IE if interrupted
* before signalled, REINTERRUPT if after signalled, or
* 0 if not interrupted.
*
* 检测线程的中断情况，通过返回状态码告知线程下一步应如何处理中断，情况有如下三种：
* 1.中断发生在被唤醒之前返回THROW_IE(需要抛出异常)
* 2.中断发生在被唤醒之后返回REINTERRUPT(需要重新中断)
* 3.无中断返回0
*/
private int checkInterruptWhileWaiting(Node node) {
return Thread.interrupted() ? (transferAfterCancelledWait(node) ?
THROW_IE : REINTERRUPT) : 0
}
小问：为神马中断发生在被唤醒之前返回THROW_IE？之后返回REINTERRUPT？
友情小提示：读者可以回顾同步队列获取锁时的处理逻辑，作用相同
- 小答：唤醒前抛出异常主要是为了快速失败，提高效率，而重新中断是要处理被唤醒后一系列
- 唤醒前： 若被唤醒之前线程被中断，说明线程此时没有获取到资源，尽快抛出异常就可以结束等待并解放生产力；
- 唤醒后： 若被唤醒后线程被中断，说明线程基本已经获取锁，这时可能要多执行一些操作，如释放锁等
9.3 判断节点是否位于同步队列
/**
* 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) {
//CONDITION只用于条件队列 || prev为空说明其一定不在同步队列中
if (node.waitStatus == Node.CONDITION || node.prev == null)
return false;
//如果next非空，它肯定在同步队列中
if (node.next != null)
return true;
//node.prev非空并不意味着在同步队列中，因此需要从后往前遍历以判断是否在同步队列中
return findNodeFromTail(node);
}
/**
* Returns true if node is on sync queue by searching backwards from tail.
*
* node.prev非空并不意味着在同步队列中，原因是CAS(放入同步队列)可能失败
* 因此需要从后往前遍历以判断其是否在同步队列中
* 由于该方法被调用时，该节点总是靠近tail，因此除非CAS失败(可能性很低)，否则几乎无须遍历
*/
private boolean findNodeFromTail(Node node) {
//从同步队列的队尾节点开始沿着prev依次往前遍历
Node t = tail;
for (;;) {
//存在，返回true
if (t == node)
return true;
//都遍历到头了还不存在，那只能返回false了
if (t == null)
return false;
//沿着prev依次往前遍历吧
t = t.prev;
}
}
小问： 为神马prev为空不在同步队列？prev非空不意味着在同步队列？next非空肯定在同步队列？
友情小提示：迷惑的小伙伴可以看看笔者的并发番@AbstractQueuedSynchronizer一文通
10.流程图
10.1 无响应中断
![条件队列.jpg-523.3kB]()
10.2 响应中断
![中断的条件队列.jpg-821.2kB]()
10.3 响应中断与超时
![超时中断的条件队列.jpg-1071.5kB]()
