[参照多篇文章,加入我自己的理解,源码改动较大]
单单抽象出生产者和消费者，还够不上是生产者／消费者模式。该模式还需要有一个缓冲区处于生产者和消费者之间，作为一个中介。生产者把数据放入缓冲区，而消费者从缓冲区取出数据
◇解耦
假设生产者和消费者分别是两个类。如果让生产者直接调用消费者的某个方法，那么生产者对于消费者就会产生依赖（也就是耦合）。将来如果消费者的代码发生变化，可能会影响到生产者。而如果两者都依赖于某个缓冲区，两者之间不直接依赖，耦合也就相应降低了。
◇支持并发（concurrency）
生产者直接调用消费者的某个方法，还有另一个弊端。由于函数调用是同步的（或者叫阻塞的），在消费者的方法没有返回之前，生产者只好一直等在那边。万一消费者处理数据很慢，生产者就会白白糟蹋大好时光。
使用了生产者／消费者模式之后，生产者和消费者可以是两个独立的并发主体（常见并发类型有进程和线程两种，后面的帖子会讲两种并发类型下的应用）。生产者把制造出来的数据往缓冲区一丢，就可以再去生产下一个数据。基本上不用依赖消费者的处理速度。其实当初这个模式，主要就是用来处理并发问题的。
◇支持忙闲不均
缓冲区还有另一个好处。如果制造数据的速度时快时慢，缓冲区的好处就体现出来了。当数据制造快的时候，消费者来不及处理，未处理的数据可以暂时存在缓冲区中。等生产者的制造速度慢下来，消费者再慢慢处理掉。
【已经生产产品数】:10 【库存量】:+10 【现仓储量为】:10
【已经生产产品数】:10 【库存量】:+20 【现仓储量为】:20
【要消费产品数量】:20 【库存量】:0 【暂时不能执行消费任务!】
【要消费产品数量】:20 【库存量】:10 【暂时不能执行消费任务!】
【要消费产品数量】:30 【库存量】:10 【暂时不能执行消费任务!】
【已经生产产品数】:10 【库存量】:+30 【现仓储量为】:30
【已经消费产品数】:30 【库存量】:-30 【现仓储量为】:0
【要消费产品数量】:50 【库存量】:0 【暂时不能执行消费任务!】
【要消费产品数量】:20 【库存量】:0 【暂时不能执行消费任务!】
【已经生产产品数】:10 【库存量】:+10 【现仓储量为】:10
【已经生产产品数】:10 【库存量】:+20 【现仓储量为】:20
【已经生产产品数】:10 【库存量】:+30 【现仓储量为】:30
【已经生产产品数】:10 【库存量】:+40 【现仓储量为】:40
【已经消费产品数】:20 【库存量】:-20 【现仓储量为】:20
【要消费产品数量】:50 【库存量】:20 【暂时不能执行消费任务!】
【已经生产产品数】:10 【库存量】:+30 【现仓储量为】:30
【已经生产产品数】:10 【库存量】:+40 【现仓储量为】:40
【已经生产产品数】:10 【库存量】:+50 【现仓储量为】:50
【已经消费产品数】:50 【库存量】:-50 【现仓储量为】:0
【现仓储量为】:0 【存量】+1
【现仓储量为】:0 【存量】-1
【现仓储量为】:0 【存量】-1
【现仓储量为】:1 【存量】+1
【现仓储量为】:0 【存量】-1
【现仓储量为】:1 【存量】+1
【现仓储量为】:0 【存量】-1
【现仓储量为】:0 【存量】-1
【现仓储量为】:2 【存量】+1
【现仓储量为】:3 【存量】+1
【现仓储量为】:4 【存量】+1
【现仓储量为】:6 【存量】+1
【现仓储量为】:7 【存量】+1
【现仓储量为】:8 【存量】+1
【现仓储量为】:9 【存量】+1
【现仓储量为】:10 【存量】+1
【现仓储量为】:11 【存量】+1
【现仓储量为】:12 【存量】+1
【现仓储量为】:13 【存量】+1
【现仓储量为】:1 【存量】+1
【现仓储量为】:14 【存量】+1
【现仓储量为】:5 【存量】+1