概述
Object 方法 | Condition 方法 | 区别 |
---|---|---|
void wait() | void await() | |
void wait(long timeout) | long awaitNanos(long nanosTimeout) | 时间单位,返回值 |
void wait(long timeout, int nanos) | boolean await(long time, TimeUnit unit) | 时间单位,参数类型,返回值 |
void notify() | void signal() | |
void notifyAll() | void signalAll() | |
- | void awaitUninterruptibly() | Condition独有 |
- | boolean awaitUntil(Date deadline) | Condition独有 |
这里先做一下说明,本文说wait方法时,是泛指wait()、wait(long timeout)、wait(long timeout, int nanos) 三个方法,当需要指明某个特定的方法时,会带上相应的参数。同样的,说notify方法时,也是泛指notify(),notifyAll()方法,await方法和signal方法以此类推。
首先,我们通过wait/notify机制来类比await/signal机制:
- 调用wait方法的线程首先必须是已经进入了同步代码块,即已经获取了监视器锁;与之类似,调用await方法的线程首先必须获取lock锁
- 调用awair方法的线程会释放已经获得的监视器锁,进入当前监视器的等待队列(wait set)中;与之类似,调用await方法的线程会释放已经获取的lock锁,进入到当前Condition对应的条件队列中。
- 调用监视器锁的notify方法会唤醒等待在该监视器锁上的线程,这些线程将开始参与锁竞争,并在获得锁之后,从wait方法处恢复执行;与之类似,调用Condition的signal方法会唤醒对应的条件队列中的线程,这些线程将开始参与锁竞争,并在获得锁后,从await方法出开始恢复执行。
实现
class BoundBuffer {
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(); //数组已满,没有空间时,挂起等待,直到数组“非满”(not full)
items[putptr] = x;
if (++putptr == items.length)
++count;
//因为放入了哟个数据,数组肯定不是空的了
//此时唤醒等待这notEmpty条件上的线程
notEmpty.singnal();
} finally {
lock.unlock();
}
// 消费者方法,从数组里面拿数据
public Object take() throws InterruptedException {
lock.lock();
try {
while (count == 0)
notEmpty.await(); // 数组是空的,没有数据可拿时,挂起等待,直到数组非空(notEmpty)
Object x = items[takeptr];
if (++takeptr == items.length) takeptr = 0;
--count;
// 因为拿出了一个数据,数组肯定不是满的了
// 此时唤醒等待这notFull条件上的线程
notFull.signal();
return x;
} finally {
lock.unlock();
}
}
}
一个典型的生产者-消费者模型。这里在同一个lock锁上,创建了两个条件队列notFull, notEmpty。当数组已满,没有存储空间时,put方法在notFull条件上等待,直到数组“not full”;当数组空了,没有数据可读时,take方法在notEmpty条件上等待,直到数组“not empty”,而notEmpty.signal()和notFull.signal()则用来唤醒等待在这个条件上的线程。
注意,上面所说的,在notFull notEmpty条件上等待事实上是指线程在条件队列(condition queue)上等待,当该线程被相应的signal方法唤醒后,将进入到sync queue中去争锁,争到锁后才能在await方法出返回。这里牵涉到两种队列-----condition queue和sync queue,他们都定义在AQS中。
同步队列 VS 条件队列
sync queue
首先,所有等待锁的线程都会被包装Node仍扔到一个同步队列中。该同步队列如下:
sync queue是一个双向链表,我们使用prev、next属性来串联节点。但是在这个同步队列中,我们一直没有用到nextWaiter属性,即使实在共享锁模式下,这一属性也只作为一个标记,指向了一个空节点,因此,在sync queue中,我们不会用它来串联节点。
condition queue
每创建一个Condition对象就会对应一个Condition队列,每一个调用Condition对象的await方法的线程都会被包装成Node扔进一个条件队列中,就像这样:
可见,每一个Condition对象对应一个Condition队列,每个Condition队列都是独立的,互不影响的。在上图中,如果我们对于线程调用了notFull.await(),则当前线程就会被包装成Node加到NotFull队列的末尾。
值得注意的时,condition queue是一个单向链表,在该链表中我们使用nextWaiter属性来串联链表。但是就像在sync queue中不会用nextWaiter属性来串联链表一样,在condition queue中,也并不会用到prev、
next属性,它们的值都为null。也就是说,在条件队列中,Node节点真正用到的属性只有三个:
- thread::代表当前正在等待某个条件的线程
- waitStatus:条件的等待状态
- nextWaiter;指向条件队列中的下一个节点
volatile int waitStatus;
static final int CANCELLED = 1;
static final int SIGNAL = -1;
static final int CONDITION = -2;
static final int PROPAGATE = -3;
在条件队列里,我们只需要关注一个值即可-------CONDITION。它表示线程处于正常的等待状态,而只要waitStatus不是CONDOTION,我们就认为线程不在等待,此时就要从等待队列中出队。
sync queue 和 condition queue 的联系
一般情况下,等待锁的sync queue和条件队列condition queue时相互独立的,彼此之间并没有任何关系。但是,当我们调用某个条件队列的signal方法,会将某个或所有等待这个条件队列中的线程唤醒,被唤醒的线程和普通线程一样需要去竞争,如果没有抢到,则同样需要被加到等待锁的sync queue中去,此时节点就从condition queue中转移到sync queue中:
但是,这里尤其要注意的是,node是被一个一个转移过去的,哪怕我们调用的是signalAll()方法也是一个一个转移过去的,而不是整个条件队列街道sync queue的末尾。
同时要注意的是,我们在sync queue中只使用prev、next来串联链表,而不使用nextWaiter;我们在condition queue中只使用nextWaiter来串联链表,而不使用prev、next。事实上,它们就是两个使用了同样的Node数据结构的完全独立的两个链表。因此将节点从condition queue中转移到sync queue中时,我们需要段俩原来的链接(nextWaiter),建立新的链接(prev、next),在某种程度上也是需要将节点一个一个地转移过去地原因之一。
入队时和出队时地锁状态
sync queue是等待锁的队列,当一个线程被包装成Node加到该队列中时,必然是没有获取锁;当该处于该队列的节点获取到了锁,他将从该队列中移除(事实上移除操作是将获取到锁的节点设为新的dummy head,并将thread属性置为null)。
condition queue是等待在特定条件下的队列,因为调用await方法时,必然时已经获得了lock锁,所以在进入condition队列前线程必然是已经获取了锁;在被包装成Node扔进条件队列后,线程将释放锁,任何挂起;当处于该队列的线程被signal方法唤醒后,由于队列中的节点在之前挂起的时候已经释放锁了,所以必须先去再次竞争锁,因此,该节点会添加到sync queue中。因此,条件队列在出队时,线程并不持有锁。
所以事实上,这两个队列的锁状态正好相反:
- condition queue:入队已经持有锁 --> 在队列中释放锁 --> 离开队列时没有锁 --> 转移到sync queue
- sync queue:入队没有锁 --> 在队列中竞争锁 --> 离开队列时获取到了锁
ConditionObject
AQS对Condition这个接口的实现主要是通过ConditionObject,上面已经说了,它的核心实现就是一个条件队列,每一个在某个condition上等待的线程都会被封装成Node对象扔进这个条件队列。
核心属性
/** First node of condition queue. */
private transient Node firstWaiter;
/** Last node of condition queue. */
private transient Node lastWaiter;
这两个属性分别代表了条件队列的对头和队尾,每当我们新建一个conditionObject对象,都会对应一个条件队列
Condition接口方法实现
await()第一部分分析
public final void await() throws InterruptedException {
// 如果当前线程在调动await()方法前已经被中断了,则直接抛出InterruptedException
if (Thread.interrupted())
throw new InterruptedException();
// 将当前线程封装成Node添加到条件队列
Node node = addConditionWaiter();
// 释放当前线程所占用的锁,保存当前的锁状态
int savedState = fullyRelease(node);
int interruptMode = 0;
// 如果当前队列不在同步队列中,说明刚刚被await, 还没有人调用signal方法,则直接将当前线程挂起
while (!isOnSyncQueue(node)) {
LockSupport.park(this); // 线程将在这里被挂起,停止运行
// 能执行到这里说明要么是signal方法被调用了,要么是线程被中断了
// 所以检查下线程被唤醒的原因,如果是因为中断被唤醒,则跳出while循环
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);
*/
}
首先是将当前线程封装成Node扔到条件队列中的addConditionWaiter方法:
addConditionWaiter
/**
* Adds a new waiter to wait queue.
* @return its new wait node
*/
private Node addConditionWaiter() {
Node t = lastWaiter;
// 如果尾节点被cancel了,则先遍历整个链表,清除所有被cancel的节点
if (t != null && t.waitStatus != Node.CONDITION) {
unlinkCancelledWaiters();
t = lastWaiter;
}
// 将当前线程包装成Node扔进条件队列
Node node = new Node(Thread.currentThread(), Node.CONDITION);
/*
Node(Thread thread, int waitStatus) { // Used by Condition
this.waitStatus = waitStatus;
this.thread = thread;
}
*/
if (t == null)
firstWaiter = node;
else
t.nextWaiter = node;
lastWaiter = node;
return node;
}
首先我们要思考的是,存在两个不同的线程同时入队的情况吗?不存在,因为能够调用await方法的线程必然是已经获取到了锁的,而获取到了锁的线程只有一个,索引这里不存在并发,因此不需要CAS操作。
在这个方法中,我就是简单的将当前线程封装成Node加到条件队列的末尾。这和将一个线程封装成Node加入等待队列略有不同:
- 节点加入sync queue是waitStatus的值为0,但节点加入condition queue时waitStatus的值为Node.CONDITION
- sync queue的头节点为dummy节点,如果队列为空,则会先创建一个dummy节点,初始化时,直接将firstWaiter和lastWaiter直接指向新建的节点就可以了。
- sync queue是一个双向队列,在节点入队后,要同时修改当前节点的前驱和前驱节点的后继;而在condition queue中,我们只修改了前驱节点的nextWaiter,也就是说,condition queue是作为单向队列来使用的。
如果入队时发现尾节点已经取消等待了,那么我们就不应该接在它的后面,此时需要调用unlinkCancelledWaiters来提出那些以今取消等待的线程:
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;
}
}
该方法将从头节点开始遍历整个队列,剔除其中waitStatus不为Node.CONDTION的节点,这里使用了两个指针firstWaiter和trail来分别记录第一个和最后一个waitStatus不为Node.CONDTION的节点,这些都是基础的链表操作,很容易理解.
fullyRelease
再借点被成功添加到队列的末尾后,我们将调用fullyRelease来释放当前线程所占用的锁:
/**
* Invokes release with current state value; returns saved state.
* Cancels node and throws exception on failure.
* @param node the condition node for this wait
* @return previous sync state
*/
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;
}
}
首先,当我们嗲用这个方法时,说明当前线程已经被封装成Node扔进条件队列了。在该方法中,我们通过release方法,释放锁。
值得注意的是,这是一次性释放了所有的锁,即对可重入锁而言,无论重入几次,这里是一次性释放完的。但是要注意**release(savedState)**方法又可能抛出IllegalMonitorStateException的,这是因为当前线程肯并不是持有锁的线程,但是之前不是说,只有持有锁的线程才能调用aeait方法吗?既然fullyRelease方法在await方法中,为啥当前线程还有可能并不是持有锁的线程呢?
因为在调用await方法时,我们其实并没有检测Thread.currentThread() == getExclusiveOwnerThread(),换句话说,也就是执行到fullyRelease这一步,我们才会检测这一点,而这一点检测是由AQS的子类实现tryRelease方法来保证的,例如:ReentrantLock对tryRelease方法的实现如下:
protected final boolean tryRelease(int releases) {
int c = getState() - releases;
if (Thread.currentThread() != getExclusiveOwnerThread())
throw new IllegalMonitorStateException();
boolean free = false;
if (c == 0) {
free = true;
setExclusiveOwnerThread(null);
}
setState(c);
return free;
}
当发现当前线程不是持有锁的线程时,我们就会进入finally块,将当前Noded额状态设置为Node.CANCELLED,这也就是为什么上面的addConditionWaiter在添加新节点钱每次都会检测尾节点是否已经被取消了。
在当前线程的锁被完成释放之后,我们能就可以调用LockSupport.park(this)把当前线程挂起,等待被signal了。但是,在挂起当前线程之前我们先用isOnSyncQueue确保了它不在sync queue中,这是为什么呢?当前线程不是在一个和sync queue无关的条件队列中吗?为什么可能会出现在sync queue中的情?
/**
* 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;
/*
* node.prev can be non-null, but not yet on queue because
* the CAS to place it on queue can fail. So we have to
* traverse from tail to make sure it actually made it. It
* will always be near the tail in calls to this method, and
* unless the CAS failed (which is unlikely), it will be
* there, so we hardly ever traverse much.
*/
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;
}
}
为了解释这一问题,我们先来看看signal方法
signalAll()
在看signalAll之前,我们首先要区分调用signalAll方法的线程进入与signal方法要唤醒的线程(等待在对应的条件队列里的线程):
- 调用signalAll方法的线程本身是已经持有了锁,现在准被释放锁了;
- 在条件队列里的线程已经在对应的条件上挂起了,等待这被signal唤醒,然后去争锁。
首先,与调用notify线程必须持有来监视器锁类似,在调用condition的signal方法时,线程也必须是已经持有了lock锁:
public final void signalAll() {
if (!isHeldExclusively())
throw new IllegalMonitorStateException();
Node first = firstWaiter;
if (first != null)
doSignalAll(first);
}
该方法首先检查当前调用signal方法的线程是不是持有锁的线程,这是通过isHeldExclusively方法来实现的,该方法是由继承AQS的子类来实现的,例如,ReentrantLock对该方法的实现为:
protected final boolean isHeldExclusively() {
return getExclusiveOwnerThread() == Thread.currentThread();
}
因为exclusiveOwnerThread保存了,当前持有锁的线程,这里只要检测它是不是等于当前线程就行了。
接下来先通过firstWaiter是否为空判断条件队列是否为空,如果条件队列不为空,则调用doSignalAll方法:
private void doSignalAll(Node first) {
lastWaiter = firstWaiter = null;
do {
Node next = first.nextWaiter;
first.nextWaiter = null;
transferForSignal(first);
first = next;
} while (first != null);
}
首先我们通过lastWaiter = firstWaiter = null;将整个条件队列清空,然后通过一个do-while循环,将原先的条件队列里面的节点一个一个拿出来(令nextWaiter = null),再通过transferForSignal方法一个一个添加到sync queue的末尾
/**
* 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) {
// 如果该节点在调用signal方法前已经被取消了,则直接跳过这个节点
if (!compareAndSetWaitStatus(node, Node.CONDITION, 0))
return false;
// 如果该节点在条件队列中正常等待,则利用enq方法将该节点添加至sync queue队列的尾部
Node p = enq(node);
int ws = p.waitStatus;
if (ws > 0 || !compareAndSetWaitStatus(p, ws, Node.SIGNAL))
LockSupport.unpark(node.thread);
return true;
}