ReentrantLock类有1个方法newCondition用来生成这个锁对象的1个条件（ConditionObject）对象，它实现了Condition接口。Condition提供了线程通讯的1套机制await和signal等线程间进行通讯的方法。。
1、适用处景
当某线程获得了锁对象，但由于某些条件没有满足，需要在这个条件上等待，直到条件满足才能够往下继续履行时，就需要用到条件锁。
这类情况下，线程主动在某条件上阻塞，当其它线程发现条件产生变化时，就能够唤醒阻塞在此条件上的线程。
2、使用示例
下面是来自JDK的1段示例代码，需要先取得某个锁对象以后，才能调用这个锁的条件对象进行阻塞。
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();
}
}
}
注意上面的代码，先是通过lock.lock取得了锁对象，然后发现条件不满足时(count==items.length)，缓存已满，没法继续往里面写入数据，这时候候就调用条件对象notFull.await()进行阻塞。
如果条件满足，就会往缓存中写入数据，同时通知等待缓存非空的线程,notEmpty.signal.
这样就实现了读线程和写线程之间的通讯
3、线程阻塞对锁的影响
上面的例子中，线程是先取得了锁对象以后，然后调用notFull.await进行的线程阻塞。在这类情况下，具有锁的线程进入阻塞，是不是可能会造成死锁。
答案固然是不是定的。由于线程在调用条件对象的await方法中，首先会释放当前的锁，然后才让自己进入阻塞状态，等待唤醒。
4、线程的条件等待、唤醒与锁对象的关系
在ReentrantLock解析中说过，AbstractQueuedSynchronizer的内部保护了1个队列，等待该锁的线程是在这个队列中。类似的，ConditionObject内部也是保护了1个队列，等待该条件的线程也构成了1个队列。
当现成调用await进入阻塞时，便会加入到ConditionObject内部的等待队列中。注意，这里是自己主动进入阻塞，除非被其它线程唤醒或被中断，否则线程将1直阻塞下去。
当其它线程调用signal唤醒阻塞的线程时，便把等待队列中的第1个节点从队列中移除，同时把节点加入到AbstractQueuedSynchronizer
锁对象内的等待队列中。为何是进入到锁的等待队列中？由于线程被唤醒以后，其实不意味着就可以立刻履行。此时，其它线程有可能正好具有这个锁，前面也已有现成在等待这个锁，所以被唤醒的线程需要进入锁的等待队列中，在前面的线程履行完成后，才能继续后续的操作。
可参考下图
5、线程是不是能同时处于条件对象的等待队列中和锁对象的等待队列中
不能。线程只有调用条件对象的await方法，才能进入这个条件对象的等待队列中。而线程在调用await方法的条件是线程已获得了锁，所以线程是在具有锁的状态下进入条件对象的等待队列的，具有锁的线程也就是正在运行的线程，是不在锁对象的等待队列中的。
只有当1个线程试着获得锁的时候，而这个锁正好又由其它线程占据的时候，线程才会进入锁的等待队列中，等待具有锁的线程履行完成，释放锁的时候被唤醒。
6、实现原理
相干代码在AbstractQueuedSynchronizer的内部类ConditionObject中可以看到。
ConditionObject有两个属性firstWaiter和lastWaiter，分别指向的是这个条件对象等待队列的头和尾。
队列的各个节点都是Node（AbstractQueuedSynchronizer的内部类）对象，通过Node对象的nextWaiter之间进行向下传递，所以，条件对象的等待队列是1个单向链表。
下面是await的源代码
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)
unlinkCancelledWaiters();
if (interruptMode
!= 0)
reportInterruptAfterWait(interruptMode);
}
首先是调用addConditionWaiter把当前线程加入到条件对象的等待队列中，然后fullyRelease来释放锁，然后通过isOnSyncQueue来检查当前线程节点是不是在锁对象的等待队列中。
为何要做这个检查？由于线程被signal唤醒的时候，是首先加入到锁对象的等待队列中的。如果没有在锁对象的等待队列中，那末说明事件还没有产生（也就是没有signal方法没有被调用），所以线程需要阻塞来等待被唤醒。
在addConditionWaiter方法中完成了等待队列的构建进程，代码以下
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;
}
线程加入队列的顺序与加入的时间1致，刚加入的线程是在队列的最后面。
下面来看线程的唤醒
public final void signal()
{
if (!isHeldExclusively())
throw new IllegalMonitorStateException();
Node first = firstWaiter;
if (first
!= null)
doSignal(first);
}
唤醒操作实际上是通过doSignal完成，注意这里传递的是firstWaiter指向的节点，也就是唤醒的时候，是从队列头开始唤醒的。
从尾部进入，从头部唤醒，所以这里的等待队列是1个FIFO队列。
private void doSignal (Node
first) {
do {
if
生活不易，码农辛苦
如果您觉得本网站对您的学习有所帮助,可以手机扫描二维码进行捐赠
