通过之前讨论的锁对象，我们知道了，由于线程按照时间片调度，所以使用锁对象来在多线程共享资源时保护未执行完成的线程安全。那么，我们再来考虑这样一种情况：
如果我的线程执行过程中因为没有满足一些必要的条件而导致线程暂停执行怎么办？
比如，我们还用银行账户系统做例子，如果有一条线程是从我的账户转出 1000 元到其他账户，可是我的账户余额不足 1000 元，那么怎么办？也许你会直接简单地想到，加上一个 if 条件语句做一下判断不就可以了，就像这样：
if (bank.getBalance(from) >= amount)
bank.transfer(from, to, amount);但是，要注意，千万不能这样写，因为，很有可能会出现这样的情况：
1. 先执行 if 语句检查我的账户余额，余额满足条件
2. 线程时间片结束被中断暂停
3. 在这期间执行了一条从我的账户取钱的线程，取出钱后余额就不足了
4. 线程恢复执行，此时余额不足但是已经执行完毕了 if 语句
由此可见，这样的代码藏有致命的 bug ，那么，我再来做修改，也许我们可以把锁对象用上，这样即使线程暂停也不会受影响了。是的，这样做确实可以防止其他线程对余额的操作，可是，这里面还是有问题：
比如，我的余额一开始就不够，这时恰好也有一个存钱的线程进来，如果钱能顺利存进来我的余额就足够了，可是，我们的锁对象却把存钱线程拒之门外，这样反而不利于线程的顺利执行了
鉴于此，我们就需要引入条件对象
通过调用 newCondition 方法可以获得一个条件对象，而且，应该养成一个给每个条件对象起个好名字的习惯，应该用其所表达的条件为其命名，这样使人一目了然。在文中的例子中，我们用 sufficientFunds（余额充足）作为条件对象的名字
class Bank{
private Condition sufficientFunds;
...
public Bank(){
...
sufficientFunds = bankLock.newCondition();
}
}如果 transfer 方法发现余额不足的时候，就会调用：
sufficientFunds.await( );
这时，当前线程就被阻塞（Blocked）了，并且放弃了锁对象，等待着其他的线程满足它所需的条件
等待获得锁的线程和调用 await 的线程存在本质上的不同，一旦一个线程调用 await 方法，它进入该条件的等待集，当锁可用时，该线程不能马上解除阻塞，相反，它处于阻塞状态，直到另一个线程调用同一条件上的 signalAll 方法为止
在本例中，当我们的条件对象调用 await 方法处于阻塞状态时，它就在等待一个转账存钱的线程来满足它的条件，因此，我们在写代码时，就可以为转账存钱的线程最后调用 sufficientFunds.signalAll( ) 方法
这一调用重新激活因为这一条件而等待的所有线程，当这些线程从等待集中移出时，它们再次成为可运行的，调度器将再次激活它们。同时，它们将试图重新进入该对象。一旦锁成为可用的，它们中的某个将从 await 调用返回，获得该锁并从被阻塞的地方继续执行。
因此，当条件对象被重新激活从 await 返回时，应该再次测试条件，因为即使我的账户已经有了收入，条件还不一定被满足
我们应该将 await 调用放入循环体中
while (条件没有被满足)
condition.await();我们还应该注意的是，当一个线程调用 await 后，它无法激活自身，只能依靠等待其他的线程来满足它的条件才能继续执行，如果没有其他线程满足它的条件，它将永远无法继续执行，这就是 死锁 现象
那么，应该在什么时候调用 signalAll 方法呢？应该在每次对象状态有利于等待线程的方向改变时调用。也就是本例中，一个账户余额发生改变时调用
综上所述，最终的 transfer 方法应该写成这样：
public void transfer(int from, int to, int amount){
bankLock.lock();
try{
while(accounts[from] < amount)
sufficientFunds.await();
// transfer funds
...
sufficientFunds.signalAll();
}
finally{
bankLock.unlock();
}
}最后还要注意，Java 中有 signal 和 signalAll 两种方法，signal 是随机解除一个等待集中的线程的阻塞状态，signalAll 是解除所有等待集中的线程的阻塞状态。signal 方法的效率会比 signalAll 高，但是它存在危险，因为它一次只解除一个线程的阻塞状态，因此，如果等待集中有多个线程都满足了条件，也只能唤醒一个，其他的线程可能会导致死锁
