对于可重入锁(ReentrantLock)的使用以及它的实现我们都已经熟悉了,本文来探究与其紧密相关的条件队列的具体实现。
在java中,所谓的条件(condition)是在已经持有锁的情况下,由newCondition方法创建出来。我们使用它做await或者signal等操作,效果是释放锁进入相关的条件队列,以及传递唤醒信号。那么也就是说调用await直到返回,会发生如下三件事:
- 释放锁
- 尝试进入相关条件队列并阻塞
- 重新获取锁
重新获取锁可能是接受到signal信号,或者由于超时或者中断,暂时不深究。
我们来看具体的代码是如何组织的:
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);
if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
break;
}
if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
interruptMode = REINTERRUPT;
if (node.nextWaiter != null) // clean up if cancelled
unlinkCancelledWaiters();
if (interruptMode != 0)
reportInterruptAfterWait(interruptMode);
}
这是个可中断版本:
- 如果中断,抛出InterruptedException异常(此时还未释放锁)。
- 构造相关队列上的节点。
- 保存锁的state状态值,递减statue值,唤醒锁队列中下一个线程。
- 当前线程不在锁队列中时,尝试阻塞当前线程(park),检查中断状态,并在中断时尝试从条件队列中移动节点到锁队列(这一步可能会合signal发生竞争,这里使用CAS-waitStatue来协作),保存中断状态值interruptMode。
- 节点已处于锁队列,调用acquireQueued,执行正常的锁获取流程,并且根据返回值与interruptMode配合重置interruptMode的值。
- 取消不要的节点(辅助操作)。
- 根据interruptMode来抛出InterruptedException或者重置异常状态,当然可能什么都不做。
我们再来看看与其紧密配合的signal操作:
public final void signal() {
if (!isHeldExclusively())
throw new IllegalMonitorStateException();
Node first = firstWaiter;
if (first != null)
doSignal(first);
}
private void doSignal(Node first) {
do {
if ( (firstWaiter = first.nextWaiter) == null)
lastWaiter = null;
first.nextWaiter = null;
} while (!transferForSignal(first) &&
(first = firstWaiter) != null);
}
final boolean transferForSignal(Node node) {
/*
* If cannot change waitStatus, the node has been cancelled.
*/
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;
}
这里的重点是transferForSignal方法:
- 尝试CAS节点的waitStatue值,假如失败,说明已经不为Node.CONDITION,返回false引起尝试下一个。
- 进入锁队列,并且尝试CAS前驱节点的waitStatue改为Node.SIGNAL,假如失败(前驱节点被取消),则唤醒当前节点(个人认为这一步不是必须,因为解锁操作中会保持唤醒)。
- 返回true结束。
以上节点的同步由锁来保证(实际上是对state变量的happens-before的应用)。
有趣的一点在于,当调用await的线程中断时,它必须通过CAS操作成功,那么在获取锁之后才会抛出中断异常,否则只是重置中断状态,也就是中断时候CAS操作与signal竞争失败的情况。
以下提供await的超时版本:
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();
}
超时版本改变了在条件队列中的阻塞方式,采用了限时阻塞,并且在超时情况下直接调用了转移节点的方法,返回值表示剩余时间。
另外两个限时版本await(long, TimeUnit)和awaitUntil与此类似,不可中断版本awaitUninterruptibly只响应signal,并且只是重置中断,不抛出中断异常。