简介
在实际的软件开发过程中，经常会碰到如下场景：
- 某个模块负责产生数据，这些数据由另一个模块来负责处理（此处的模块是广义的，可以是类、函数、线程、进程等）。
- 产生数据的模块，就形象地称为生产者；而处理数据的模块，就称为消费者。
- 单单抽象出生产者和消费者，还够不上是生产者／消费者模式。
- 该模式还需要有一个缓冲区处于生产者和消费者之间，作为一个中介。
-
生产者把数据放入缓冲区，而消费者从缓冲区取出数据。
大概的结构如下图。
比较直白的一个寄信的例子:
1、你把信写好——相当于生产者制造数据
2、你把信放入邮筒——相当于生产者把数据放入缓冲区
3、邮递员把信从邮筒取出——相当于消费者把数据取出缓冲区
4、邮递员把信拿去邮局做相应的处理——相当于消费者处理数据
- 优点
可能会有这样的疑问：这个缓冲区有什么用？为什么不让生产者直接调用消费者的某个函数，直接把数据传递过去？搞出这么一个缓冲区干什么？
其实这里面是大有讲究的，大概有如下一些好处。
解耦
- 假设生产者和消费者分别是两个类。
- 如果让生产者直接调用消费者的某个方法，那么生产者对于消费者就会产生依赖（也就是耦合）。
- 将来如果消费者的代码发生变化，可能会影响到生产者。
- 而如果两者都依赖于某个缓冲区，两者之间不直接依赖，耦合也就相应降低了。
接着上述的例子，如果不使用邮筒（也就是缓冲区），你必须得把信直接交给邮递员。有同学会说，直接给邮递员不是挺简单的嘛？其实不简单，你必须得认识谁是邮递员，才能把信给他（光凭身上穿的制服，万一有人假冒，就惨了）。这就产生和你和邮递员之间的依赖（相当于生产者和消费者的强耦合）。万一哪天邮递员换人了，你还要重新认识一下（相当于消费者变化导致修改生产者代码）。而邮筒相对来说比较固定，你依赖它的成本就比较低（相当于和缓冲区之间的弱耦合）。
支持并发（concurrency）
-
生产者直接调用消费者的某个方法，还有另一个弊端。
-
由于函数调用是同步的（或者叫阻塞的），在消费者的方法没有返回之前，生产者只好一直等在那边。万一消费者处理数据很慢，生产者就会白白糟蹋大好时光。
-
架构设计：生产者/消费者模式
架构设计：生产者/消费者模式
架构设计：生产者/消费者模式