架构设计：生产者/消费者模式 第1页：“生产者／消费者模式”介绍

架构设计：生产者/消费者模式 第1页：“生产者／消费者模式”介绍

★简介

    在实际的软件开发过程当中，常常会碰到以下场景：某个模块负责产生数据，这些数据由另外一个模块来负责处理（此处的模块是广义的，能够是类、函数、线程、进程等）。产生数据的模块，就形象地称为生产者；而处理数据的模块，就称为消费者。

    单单抽象出生产者和消费者，还够不上是生产者／消费者模式。该模式还须要有一个缓冲区处于生产者和消费者之间，做为一个中介。生产者把数据放入缓冲区，而消费者从缓冲区取出数据。大概的结构以下图。

    为了避免至于太抽象，咱们举一个寄信的例子（虽然说这年头寄信已经不时兴，但这个例子仍是比较贴切的）。假设你要寄一封平信，大体过程以下：

    一、你把信写好——至关于生产者制造数据

    二、你把信放入邮筒——至关于生产者把数据放入缓冲区

    三、邮递员把信从邮筒取出——至关于消费者把数据取出缓冲区

    四、邮递员把信拿去邮局作相应的处理——至关于消费者处理数据

    ★优势

    可能有同窗会问了：这个缓冲区有什么用捏？为何不让生产者直接调用消费者的某个函数，直接把数据传递过去？搞出这么一个缓冲区做甚？

    其实这里面是大有讲究的，大概有以下一些好处。

    ◇解耦

    假设生产者和消费者分别是两个类。若是让生产者直接调用消费者的某个方法，那么生产者对于消费者就会产生依赖（也就是耦合）。未来若是消费者的代码发生变化，可能会影响到生产者。而若是二者都依赖于某个缓冲区，二者之间不直接依赖，耦合也就相应下降了。

    接着上述的例子，若是不使用邮筒（也就是缓冲区），你必须得把信直接交给邮递员。有同窗会说，直接给邮递员不是挺简单的嘛？其实不简单，你必须得认识谁是 邮递员，才能把信给他（光凭身上穿的制服，万一有人假冒，就惨了）。这就产生和你和邮递员之间的依赖（至关于生产者和消费者的强耦合）。万一哪天邮递员换 人了，你还要从新认识一下（至关于消费者变化致使修改生产者代码）。而邮筒相对来讲比较固定，你依赖它的成本就比较低（至关于和缓冲区之间的弱耦合）。

    ◇支持并发（concurrency）

    生产者直接调用消费者的某个方法，还有另外一个弊端。因为函数调用是同步的（或者叫阻塞的），在消费者的方法没有返回以前，生产者只好一直等在那边。万一消费者处理数据很慢，生产者就会白白糟蹋大好时光。

    使用了生产者／消费者模式以后，生产者和消费者能够是两个独立的并发主体（常见并发类型有进程和线程两种，后面的帖子会讲两种并发类型下的应用）。生产者把制造出来的数据往缓冲区一丢，就能够再去生产下一个数据。基本上不用依赖消费者的处理速度。

    其实当初这个模式，主要就是用来处理并发问题的。

    从寄信的例子来看。若是没有邮筒，你得拿着信傻站在路口等邮递员过来收（至关于生产者阻塞）；又或者邮递员得挨家挨户问，谁要寄信（至关于消费者轮询）。无论是哪一种方法，都挺土的。

    ◇支持忙闲不均

    缓冲区还有另外一个好处。若是制造数据的速度时快时慢，缓冲区的好处就体现出来了。当数据制造快的时候，消费者来不及处理，未处理的数据能够暂时存在缓冲区中。等生产者的制造速度慢下来，消费者再慢慢处理掉。

    为了充分复用，咱们再拿寄信的例子来讲事。假设邮递员一次只能带走1000封信。万一某次碰上情人节（也多是圣诞节）送贺卡，须要寄出去的信超过1000封，这时候邮筒这个缓冲区就派上用场了。邮递员把来不及带走的信暂存在邮筒中，等下次过来时再拿走。