今天打算来介绍一下“生产者／消费者模式”这玩意儿在很多开发领域都能派上用场。由于该模式很重要打算分几个帖子来介绍。今天这个帖子先来扫盲一把如果伱对这个模式已经比较了解，请跳过本扫盲帖直接看。

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

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

为了不至于太抽象我们举一个寄信的例子（虽说这年头寄信已经不时兴，但这个例子还是比较贴切的）假设你要寄一封平信，大致过程如下：

1、你把信寫好——相当于生产者制造数据

2、你把信放入邮筒——相当于生产者把数据放入缓冲区

3、邮递员把信从邮筒取出——相当于消费者把数据取出缓冲区

4、邮递员把信拿去邮局做相应的处理——相当于消费者处理数据

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

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

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

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

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

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

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

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

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

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

费了这么多口水希望原先不太了解生产者／消费者模式的同学能够明白它是怎么一回事。然後在下一个帖子中我们来说说。

另外为了方便阅读，把本系列帖子的目录整理如下：

既然已经搞过扫盲了那接下来应该开始聊一些具体的编程技术问题了。不过在进入具体的技术细节之前咱们先要搞明白一个问题：如何确定数据单元？只有把数据单元分析清楚后媔的技术设计才好搞。

何谓数据单元捏简单地说，每次生产者放到缓冲区的就是一个数据单元；每次消费者从缓冲区取出的，也是一個数据单元对于中寄信的例子，我们可以把每一封单独的信件看成是一个数据单元

不过光这么介绍，太过于简单无助于大伙儿分析絀这玩意儿。所以后面咱们来看一下数据单元需要具备哪些特性。搞明白这些特性之后就容易从复杂的业务逻辑中分析出适合做数据單元的东西了。

分析数据单元需要考虑如下几个方面的特性：

首先，数据单元必须关联到某种业务对象在考虑该问题的时候，你必须罙刻理解当前这个生产者／消费者模式所对应的业务逻辑才能够作出合适的判断。

由于“寄信”这个业务逻辑比较简单所以大伙儿很嫆易就可以判断出数据单元是啥。但现实生活中往往没这么乐观。大多数业务逻辑都比较复杂当中包含的业务对象是层次繁多、类型各异。在这种情况下就不易作出决策了。

这一步很重要如果选错了业务对象，会导致后续程序设计和编码实现的复杂度大为上升增加了开发和维护成本。

（例如在进行MPEG-4码流缓冲时，可考虑以一帧作为数据单元也可以以一个GOP作为数据单元，视具体业务而定）

所谓完整性就是在传输过程中，要保证该数据单元的完整要么整个数据单元被传递到消费者，要么完全没有传递到消费者不允许出现部分傳递的情形。

对于寄信来说你不能把半封信放入邮筒；同样的，邮递员从邮筒中拿信也不能只拿出信的一部分。

（例如在进行MPEG-4码流緩冲时，数据必须一整帧或一个完整的GOP）

所谓独立性就是各个数据单元之间没有互相依赖，某个数据单元传输失败不应该影响已经完成傳输的单元；也不应该影响尚未传输的单元

为啥会出现传输失败捏？假如生产者的生产速度在一段时间内一直超过消费者的处理速度那就会导致缓冲区不断增长并达到上限，之后的数据单元就会被丢弃如果数据单元相互独立，等到生产者的速度降下来之后后续的数據单元继续处理，不会受到牵连；反之如果数据单元之间有某种耦合，导致被丢弃的数据单元会影响到后续其它单元的处理那就会使程序逻辑变得非常复杂。

对于寄信来说某封信弄丢了，不会影响后续信件的送达；当然更不会影响已经送达的信件

（例如，在进行MPEG-4码鋶缓冲时帧与帧之间一般有差向关联，而一个GOP是独立的）

前面提到数据单元需要关联到某种业务对象。那么数据单元和业务对象是否偠一一对应捏很多场合确实是一一对应的。

不过有时出于性能等因素的考虑，也可能会把N个业务对象打包成一个数据单元（比如MPEG-4码流Φ多帧组成GOP）那么，这个N该如何取值就是颗粒度的考虑了颗粒度的大小是有讲究的。太大的颗粒度可能会造成某种浪费；太小的颗粒喥可能会造成性能问题颗粒度的权衡要基于多方面的因素，以及一些经验值的考量

还是拿寄信的例子。如果颗粒度过小（比如设定为1）那邮递员每次只取出1封信。如果信件多了那就得来回跑好多趟，浪费了时间

如果颗粒度太大（比如设定为100），那寄信的人得等到湊满100封信才拿去放入邮筒假如平时很少写信，就得等上很久也不太爽。

可能有同学会问：生产者和消费者的颗粒度能否设置成不同大尛（比如对于寄信人设置成1对于邮递员设置成100）。当然理论上可以这么干，但是在某些情况下会增加程序逻辑和代码实现的复杂度後面讨论具体技术细节时，或许会聊到这个问题

（例如，在进行MPEG-4码流缓冲时视情况一次可缓冲多个GOP）

好，数据单元的话题就说到这唏望通过本帖子，大伙儿能够搞明白数据单元到底是怎么一回事下一个帖子，咱们来聊一下“”技术上如何实现。

经过前面两个帖子嘚铺垫今天终于开始聊一些具体的编程技术了。由于不同的缓冲区类型、不同的并发场景对于具体的技术实现有较大的影响为了深入淺出、便于大伙儿理解，咱们先来介绍最传统、最常见的方式也就是单个生产者对应单个消费者，当中用队列（FIFO）作缓冲

关于并发的場景，在之前的帖子“”中已经专门论述了进程和线程各自的优缺点，两者皆不可偏废所以，后面对各种缓冲区类型的介绍都会同时提及进程方式和线程方式

先来说一下并发线程中使用队列的例子，以及相关的优缺点

在线程方式下，生产者和消费者各自是一个线程生产者把数据写入队列头（以下简称push），消费者从队列尾部读出数据（以下简称pop）当队列为空，消费者就稍息（稍事休息）；当队列滿（达到最大长度）生产者就稍息。整个流程并不复杂

那么，上述过程会有什么问题捏一个主要的问题是关于内存分配的性能开销。对于常见的队列实现：在每次push时可能涉及到堆内存的分配；在每次pop时，可能涉及堆内存的释放假如生产者和消费者都很勤快，频繁哋push、pop那内存分配的开销就很可观了。对于内存分配的开销用Java的同学可以参见前几天的帖子“”；对于用C/C++的同学，想必对OS底层机制会更清楚应该知道分配堆内存（new或malloc）会有加锁的开销和的开销。

那该怎么办捏请听下文分解，关于“”

另外，由于两个线程共用一个队列自然就会涉及到线程间诸如同步啊、互斥啊、死锁啊等等劳心费神的事情。好在“操作系统”这门课程对此有详细介绍学过的同学應该还有点印象吧？对于没学过这门课的同学也不必难过，网上相关的介绍挺多的（比如“”）大伙自己去瞅一瞅。关于这方面的细節咱今天就不多啰嗦了。

这会儿要细谈的是同步和互斥的性能开销。在很多场合中诸如信号量、互斥量等玩意儿的使用也是有不小嘚开销的（某些情况下，也可能导致用户态／核心态切换）如果像刚才所说，生产者和消费者都很勤快那这些开销也不容小觑啊。

这叒该咋办捏请听下文的分解，关于“”

刚才尽批判了队列的缺点，难道队列方式就一无是处非也。由于队列是很常见的数据结构夶部分编程语言都内置了队列的支持（具体介绍见“”），有些语言甚至提供了线程安全的队列（比如JDK 1.5引入的）因此，开发人员可以捡現成避免了重新发明轮子。

所以假如你的数据流量不是很大，采用队列缓冲区的好处还是很明显的：逻辑清晰、代码简单、维护方便比较符合KISS原则。

说完了线程的方式再来介绍基于进程的并发。

跨进程的生产者／消费者模式非常依赖于具体的进程间通讯（IPC）方式。而IPC的种类名目繁多不便于挨个列举（毕竟口水有限）。因此咱们挑选几种跨平台、且编程语言支持较多的IPC方式来说事儿

感觉管道是朂像队列的IPC类型。生产者进程在管道的写端放入数据；消费者进程在管道的读端取出数据整个的效果和线程中使用队列非常类似，区别茬于使用管道就无需操心线程安全、内存分配等琐事（操作系统暗中都帮你搞定了）

管道又分和两种，今天主要聊匿名管道因为命名管道在不同的操作系统下差异较大（比如Win32和POSIX，在命名管道的API接口和功能实现上都有较大差异；有些平台不支持命名管道比如Windows CE）。除了操莋系统的问题对于有些编程语言（比如Java）来说，命名管道是无法使用的所以我一般不推荐使用这玩意儿。

其实匿名管道在不同平台上嘚API接口也是有差异的（比如Win32的CreatePipe和POSIX的pipe，用法就很不一样）但是我们可以仅使用标准输入和标准输出（以下简称stdio）来进行数据的流入流出。然后利用shell的管道符把生产者进程和消费者进程关联起来（没听说过这种手法的同学可以看“”）。实际上很多操作系统（尤其是POSIX风格的）自带的命令都充分利用了这个特性来实现数据的传输（比如more、grep等）。

1、基本上所有操作系统都支持在shell方式下使用管道符因此很容噫实现跨平台。

2、大部分编程语言都能够操作stdio因此跨编程语言也就容易实现。

3、刚才已经提到管道方式省却了线程安全方面的琐事。囿利于降低开发、调试成本

当然，这种方式也有自身的缺点：

1、生产者进程和消费者进程必须得在同一台主机上无法跨机器通讯。这個缺点比较明显

2、在一对一的情况下，这种方式挺合用但如果要扩展到一对多或者多对一，那就有点棘手了所以这种方式的扩展性偠打个折扣。假如今后要考虑类似的扩展这个缺点就比较明显。

3、由于管道是shell创建的对于两边的进程不可见（程序不同用户看到不同頁面的只是stdio）。在某些情况下导致程序不便于对管道进行操纵（比如调整管道缓冲区尺寸）。这个缺点不太明显

4、最后，这种方式只能单向传数据好在大多数情况下，消费者进程不需要传数据给生产者进程万一你确实需要信息反馈（从消费者到生产者），那就费劲叻可能得考虑换种IPC方式。

顺便补充几个注意事项大伙儿留意一下：

1、对stdio进行读写操作是以阻塞方式进行。比如管道中没有数据消费鍺进程的读操作就会一直停在哪儿，直到管道中重新有数据

2、由于stdio内部带有自己的缓冲区（这缓冲区和管道缓冲区是两码事），有时会導致一些不太爽的现象（比如生产者进程输出了数据但消费者进程没有立即读到）。具体的细节大伙儿可以看“”。

基于TCP方式的SOCKET通讯昰又一个类似于队列的IPC方式它同样保证了数据的顺序到达；同样有缓冲的机制。而且这玩意儿也是跨平台和跨语言的和刚才介绍的shell管噵符方式类似。

SOCKET相比shell管道符的方式有啥优点捏？主要有如下几个优点：

1、SOCKET方式可以跨机器（便于实现分布式）这是主要优点。

2、SOCKET方式便于将来扩展成为多对一或者一对多这也是主要优点。

3、SOCKET可以设置阻塞和非阻塞方法用起来比较灵活。这是次要优点

4、SOCKET支持双向通訊，有利于消费者反馈信息

当然有利就有弊。相对于上述shell管道的方式使用SOCKET在编程上会更复杂一些。好在前人已经做了大量的工作搞絀很多SOCKET通讯库和框架给大伙儿用（比如C++的库、Python的）。借助于这些第三方的库和框架SOCKET方式用起来还是比较爽的。由于具体的网络通讯库该怎么用不是本系列的重点此处就不细说了。

虽然TCP在很多方面比UDP可靠但鉴于跨机器通讯先天的不可预料性（比如网线可能被某傻X给拔错叻，网络的忙闲波动可能很大）在程序设计上我们还是要多留一手。具体该如何做捏可以在生产者进程和消费者进程内部各自再引入基于线程的“生产者／消费者模式”。这话听着像绕口令为了便于理解，画张图给大伙儿瞅一瞅

这么做的关键点在于把代码分为两部汾：生产线程和消费线程属于和业务逻辑相关的代码（和通讯逻辑无关）；发送线程和接收线程属于通讯相关的代码（和业务逻辑无关）。

这样的好处是很明显的具体如下：

1、能够应对暂时性的网络故障。并且在网络故障解除后能够继续工作。

2、网络故障的应对处理方式（比如断开后的尝试重连）只影响发送和接收线程，不会影响生产线程和消费线程（业务逻辑部分）

3、具体的SOCKET方式（阻塞和非阻塞）只影响发送和接收线程，不影响生产线程和消费线程（业务逻辑部分）

4、不依赖TCP自身的发送缓冲区和接收缓冲区。（默认的TCP缓冲区的夶小可能无法满足实际要求）

5、业务逻辑的变化（比如业务需求变更）不影响发送线程和接收线程

针对上述的最后一条，再多啰嗦几句如果整个业务系统中有多个进程是采用上述的模式，那或许可以重构一把：在业务逻辑代码和通讯逻辑代码之间切一刀把业务逻辑无關的部分封装成一个通讯中间件（说中间件显得比较牛X :-）。如果大伙儿对这玩意儿有兴趣以后专门开个帖子聊。

咱们介绍一下环形缓沖区的话题。

提及了队列缓冲区可能存在的性能问题及解决方法：环形缓冲区今天就专门来描述一下这个话题。

为了防止有人给咱扣上“过度设计”的大帽子事先声明一下：只有当存储空间的分配／释放非常频繁并且确实产生了明显的影响，你才应该考虑环形缓冲区的使用否则的话，还是老老实实用最基本、最简单的吧还有一点需要说明一下：本文所提及的“存储空间”，不仅包括内存还可能包括诸如硬盘之类的存储介质。

★环形缓冲区 vs 队列缓冲区

在介绍环形缓冲区之前咱们先来回顾一下普通的队列。普通的队列有一个写入端囷一个读出端队列为空的时候，读出端无法读取数据；当队列满（达到最大尺寸）时写入端无法写入数据。

对于使用者来讲环形缓沖区和队列缓冲区是一样的。它也有一个写入端（用于push）和一个读出端（用于pop）也有缓冲区“满”和“空”的状态。所以从队列缓冲區切换到环形缓冲区，对于使用者来说能比较平滑地过渡

虽然两者的对外接口差不多，但是内部结构和运作机制有很大差别队列的内蔀结构此处就不多啰嗦了。重点介绍一下环形缓冲区的内部结构

大伙儿可以把环形缓冲区的读出端（以下简称R）和写入端（以下简称W）想象成是两个人在体育场跑道上追逐（R追W）。当R追上W的时候就是缓冲区为空；当W追上R的时候（W比R多跑一圈），就是缓冲区满

为了形象起见，去找来一张图并略作修改如下：

从上图可以看出，环形缓冲区所有的push和pop操作都是在一个固定的存储空间内进行而队列缓冲区在push嘚时候，可能会分配存储空间用于存储新元素；在pop时可能会释放废弃元素的存储空间。所以环形方式相比队列方式少掉了对于缓冲区え素所用存储空间的分配、释放。这是环形缓冲区的一个主要优势

如果你手头已经有现成的环形缓冲区可供使用，并且你对环形缓冲区嘚内部实现不感兴趣可以跳过这段。

◇数组方式 vs 链表方式

环形缓冲区的内部实现即可基于数组（此处的数组，泛指连续存储空间）实現也可基于链表实现。

数组在物理存储上是一维的连续线性结构可以在初始化时，把存储空间一次性分配好这是数组方式的优点。泹是要使用数组来模拟环你必须在逻辑上把数组的头和尾相连。在顺序遍历数组时对尾部元素（最后一个元素）要作一下特殊处理。訪问尾部元素的下一个元素时要重新回到头部元素（第0个元素）。如下图所示：

使用链表的方式正好和数组相反：链表省去了头尾相連的特殊处理。但是链表在初始化的时候比较繁琐而且在有些场合（比如后面提到的跨进程的IPC）不太方便使用。

环形缓冲区要维护两个索引分别对应写入端（W）和读取端（R）。写入（push）的时候先确保环没满，然后把数据复制到W所对应的元素最后W指向下一个元素；读取（pop）的时候，先确保环没空然后返回R对应的元素，最后R指向下一个元素

上述的操作并不复杂，不过有一个小小的麻烦：空环和满环嘚时候R和W都指向同一个位置！这样就无法判断到底是”空”还是”满”。大体上有两种方法可以解决该问题

办法1：始终保持一个元素鈈用

当空环的时候，R和W重叠当W比R跑得快，追到距离R还有一个元素间隔的时候就认为环已经满。当环内元素占用的存储空间较大的时候这种办法显得很土（浪费空间）。

如果不喜欢上述办法还可以采用额外的变量来解决。比如可以用一个整数记录当前环中已经保存的え素个数（该整数>=0）当R和W重叠的时候，通过该变量就可以知道是”空”还是”满”

由于环形缓冲区本身就是要降低存储空间分配的开銷，因此缓冲区中元素的类型要选好尽量存储值类型的数据，而不要存储指针（引用）类型的数据因为指针类型的数据又会引起存储涳间（比如堆内存）的分配和释放，使得环形缓冲区的效果打折扣

刚才介绍了环形缓冲区内部的实现机制。按照的惯例我们来介绍一丅在线程和进程方式下的使用。

如果你所使用的编程语言和开发库中带有现成的、成熟的环形缓冲区强烈建议使用现成的库，不要重新淛造轮子；确实找不到现成的才考虑自己实现。如果你纯粹是业余时间练练手那另当别论。

和线程中的队列缓冲区类似线程中的环形缓冲区也要考虑线程安全的问题。除非你使用的环形缓冲区的库已经帮你实现了线程安全否则你还是得自己动手搞定。线程方式下的環形缓冲区用得比较多相关的网上资料也多，下面就大致介绍几个

对于C++的程序员，强烈推荐使用提供的模板该模板最开始是在boost 1.35版本Φ引入的。鉴于boost在C++社区中的地位大伙儿应该可以放心使用该模板。

对于C程序员可以去看看开源项目，不过该项目是GPL协议的不太爽；洏且活跃度不太高；而且只有一个开发人员。大伙儿慎用！建议只拿它当参考

对于C#程序员，可以参考

进程间的环形缓冲区，似乎少有現成的库可用大伙儿只好自己动手、丰衣足食了。

适用于进程间环形缓冲的IPC类型常见的有和文件。在这两种方式上进行环形缓冲通瑺都采用数组的方式实现。程序事先分配好一个固定长度的存储空间然后具体的读写操作、判断”空”和”满”、元素存储等细节就可參照前面所说的来进行。

共享内存方式的性能很好适用于数据流量很大的场景。但是有些语言（比如Java）对于共享内存不支持因此，该方式在多语言协同开发的系统中会有一定的局限性。

而文件方式在编程语言方面支持很好几乎所有编程语言都支持操作文件。但它可能会受限于磁盘读写（Disk I/O）的性能所以文件方式不太适合于快速数据传输；但是对于某些“”很大的场合，文件方式是值得考虑的

对于進程间的环形缓冲区，同样要考虑好进程间的同步、互斥等问题限于篇幅，此处就不细说了

，咱们来聊一下双缓冲区的使用

“双缓沖区”是一个应用很广的手法。该手法用得最多的地方想必是屏幕绘制相关的领域（主要是为了减少屏幕闪烁）另外，在设备驱动和工控方面双缓冲也经常被使用。不过今天要聊的并不是针对上述的某个具体领域，而是侧重于并发方面的同步/互斥开销另外提醒一下，双缓冲方式和前面提到的队列缓冲、环形缓冲是可以结合使用滴

记得前几天在时，提及了普通队列缓冲区的两个性能问题：“内存分配的开销”和“同步/互斥的开销”（健忘的同学先回去看看复习一下）。“内存分配的开销”已经在的时候解决了而今天要介绍的双緩冲区，就是冲着同步/互斥的开销来的

为了防止有人给咱扣上“过度设计”的大帽子，又得来一个事先声明：只有当同步或互斥的开销非常明显的时候你才应该考虑双缓冲区的使用。否则的话大伙儿还是老老实实用最基本、最简单的队列缓冲区吧。

前面说了一通废话现在开始切入正题，说说具体实现

所谓“双缓冲区”，故名思义就是要有俩缓冲区（简称A和B）这俩缓冲区，总是一个用于生产者叧一个用于消费者。当俩缓冲区都操作完再进行一次切换（先前被生产者写入的转为消费者读出，先前消费者读取的转为生产者写入）由于生产者和消费者不会同时操作同一个缓冲区（不发生冲突），所以就不需要在读写每一个的时候都进行同步/互斥操作顺便提一下，这又一次展现了空间换时间的优化思路

但是光有俩缓冲区还不够。为了真正做到“不冲突”还得再搞两个互斥锁（简称La和Lb），分别對应俩缓冲区生产者或消费者如果要操作某个缓冲区，必须先拥有对应的互斥锁补充一句：要达到“不冲突”的效果，其实可以有多種搞法今天只是挑一个简单的来聊。

为了加深某些同学的理解再描述一下双缓冲区的几种状态。

◇俩缓冲区都在使用的状态（并发读寫）

大多数情况下生产者和消费者都处于并发读写状态。不妨设生产者写入A消费者读取B。在这种状态下生产者拥有锁La；同样的，消費者拥有锁Lb由于俩缓冲区都是处于独占状态，因此每次读写缓冲区中的元素（）都不需要再进行加锁、解锁操作这是节约开销的主要來源。

◇单个缓冲区空闲的状态

由于两个并发实体的速度会有差异必然会出现一个缓冲区已经操作完，而另一个尚未操作完不妨假设苼产者快于消费者。

在这种情况下当生产者把A写满的时候，生产者要先释放La（表示它已经不再操作A）然后尝试获取Lb。由于B还没有被读涳Lb还被消费者持有，所以生产者进入发呆（Suspend）状态

过了若干时间，消费者终于把B读完这时候，消费者也要先释放Lb然后尝试获取La。甴于La刚才已经被生产者释放所以消费者能立即拥有La并开始读取A的数据。而由于Lb被消费者释放所以刚才发呆的生产者会缓过神来（Resume）并擁有Lb，然后生产者继续往B写入数据

经过上述几个步骤，俩缓冲区完成了对调变为：生产者写入B，消费者读取A

（对于双缓冲，可引入序列号机制）

本来单个缓冲区的生产者/消费者问题就已经是教科书的经典问题了，现在搞出俩缓冲区所以就更加耗费脑细胞了。一不尛心就会搞出些并发的Bug，而且并发的Bug还很难调试和测试（这也就是为啥不要轻易使用该玩意儿的原因）

假如把前面介绍的操作步骤调換一下顺序：生产者或消费者在操作完当前的缓冲区之后，先去获取另一个缓冲区的锁再来释放当前缓冲区的锁。那会咋样捏

一旦两個并发实体同时处理完各自缓冲区，然后同时去获取对方拥有的锁那就会出现典型的死锁（死锁的详细解释参见“”）场景。它俩从此陷入万劫不复的境地

介绍完并发问题，按照的惯例最后再来介绍一下双缓冲区在某些场合的应用。

在线程方式下首先要考虑的是缓沖区的类型：到底用队列方式还是环形方式。这方面的选择依据在的时候已经阐述过了此处不再啰嗦（省去不少口水）。

另一个需要注意的是某些编程语言或者程序库提供了的线程安全的缓冲区（比如JDK 1.5引入的）。由于这种缓冲区会自动为每次的读写进行同步/互斥所以僦把双缓冲的优势抵消掉了。因此大伙儿在进行缓冲区选型的时候要避开这类缓冲区。

在进程间使用双缓冲先得考察不同IPC类型的特点。由于今天讨论双缓冲的目的是降低同步/互斥的开销对于那些已经封装了同步/互斥的IPC类型，就没太大必要再去搞双缓冲了（单凭这条就足以让好多种IPC出局）剩下的IPC类型中，比较适合用双缓冲的主要是：共享内存和文件非常凑巧，这两个玩意儿的特点和适用范围在里面吔已经介绍过了俺又可以节省不少口水

将5个字母“ooops"按此顺序入栈则有種不同的出栈顺序可以仍然得到“oo

来源：网考网 【网考网：网络考试学习专业网站】

【单选题】 将5个字母“ooops"按此顺序入栈，则有( )种不同的絀栈顺序可以仍然得到“ooops”