原文地址：http://blog.csdn.net/zhshulin/article/details/50762465
下面只是简单的介绍一下，具体代码可以看我分享的代码，注释都有
说到线程间协作，不得不提到经典的生产者与消费者模型：有一个商品队列，生产者想队列中添加商品，消费者取出队列中的商品；显然，如果队列为空，消费者应该等待生产者产生商品才能消费；如果队列满了，生产者需要等待消费者消费之后才能生产商品。队列就是这个模型中的临界资源，当队列为空时，而消费者获得了该对象的锁，如果不释放，那么生产者无法获得对象锁，而消费者无法消费对象，就进入了死锁状态；反之队列满时，生产者不释放对象锁也会造成死锁。这是我们不希望看到的，所以就有了线程间协作来解决这个问题。
其实说到生产者与消费者模型，我们不能简单的知道怎么实现，而是需要知这种模型的使用场景：主要是为了复用和解耦，常见的消息框架（非常经典的一种生产者消费者模型的使用场景）ActiveMQ。发送端和接收端用Topic进行关联。
JAVA语言中，如何实现线程间协作呢？比较常见的方法就是利用Object.wait()，Object.notify()和Condition。
先看看这几个方法究竟有什么作用？为什么利用它们就可以实现线程间协作了呢？
首先分析一下wait()/notify()/notifyAll()这三个Object监视器方法，比较早的方法，JDK1.5之前：
1、上述三个方法都是Object类中的本地方法，且为final，无法被重写；且这三个方法都必须在同步块或者同步方法synchronized(this)中才能执行；
2、当前线程必须拥有该对象的锁，才能执行wait()方法，wait()方法会阻塞当前线程，并且释放对象锁；
3、notify()方法可以唤醒一个（1/N）正在等待这个资源锁的线程，但是不保证被唤醒的线程一定可以获得这个对象锁。
4、notifyAll()方法可以唤醒所有正在等待这个资源锁的线程，然后让它们去竞争资源锁，具体哪个能拿到就不知道了。
下面我们再来分析一下JAVA中的Condition又是什么呢？java.util.concurrent.locks.Condition是为了替代Object监视器方法。那么我们不经就要问：Condition相比较Object监视器的三个方法有什么差别呢？下面我们就来对比看看，到底差别在哪里？下面这个表展示了它们方法之间的共性。
使用Condition中，使用Lock来替代Synchronized关键字来实现操作的原子性，实现对临界资源的加锁与解锁，同样的，Condition中提供的三个方法也需要在“同步块”中进行。Condition相比较而言，强大的地方在于它能够精确的控制多线程的休眠与唤醒（注意是唤醒，唤醒并不表示该线程一定能够得到资源锁），这个意思就是有A/B/C/D四个线程共享Z资源，如果A占用了Z，并且调用了b_condition.notify()就可以释放资源唤醒B线程，而Object的nofity就无法保证B/C/D中会被唤醒哪一个了。其实多数线程间协作实用上述两种方式都可以实现，但是Sun推荐使用Condition来实现...我认为具体看你喜欢了，以及使用的熟练程度，除非你特别希望精确控制哪个线程被唤醒。
其实在我分享的两个代码的实现结果中，如果不加上Thread.sleep()来让线程睡眠，我们看到的结果就像是单线程一样，生产者填满队列，消费者清空队列。为什么会这样呢？我们注意到，在“同步块”中，如果不是队列的临界值（0、maxSize）,仅仅是调用notify来唤醒一个等待该资源的线程，那么这个线程本身并没有进入等待状态，这个线程在释放这个锁之后会加入这个锁的竞争中，到底谁得到这个锁，其实也说不清楚，修改sleep的睡眠时间，可以看到从100毫秒到2000毫秒，设置不同的休眠时间，可以观察到生产者与消费者也不会出现交替进行，还是随机的。那么为什么要用Condition实现对确定线程的唤醒操作呢？唤醒了又不一定得到锁，这个需要使用到await()来让当前线程必须等到其他线程来唤醒才能控制生产者与消费者的交替执行。大家可以尝试一下：
在produce.signal()和consume.signal后面分别加上：consume.await()和produce.await即可实现生产者和消费者（多个线程也可以控制任意两个线程交替执行）的交替执行，这个呢，使用Object监视器方法在多个线程的情况下是不可能实现的，但是仅仅2个线程还是可以的。上述列子中，如果有多个消费者，那么如何在生产者完成生产后就只唤醒消费者线程呢？同样，用Condition实现就非常简单了，如果使用Object监视器类也可以实现，大家不妨想一下，但是相对复杂，编程过程中容易出现死锁。
来源：oschina
链接：https://my.oschina.net/u/2657939/blog/636873