架构设计：生产者消费者模式
labview生产者消费者
生产者/消费者模式(1)_前言statemice的LabVIEW程序设计模式(五)—生产者/消费者模式(1)_前言再次回顾“基本状态机模式”的6个缺点，只剩下第6个缺点无法在上述的“状态机和事件结构的结合模式”中被解决。
(1) 任何时刻只能有一个状态在运行这个问题也许有些多余，但是在实际的应用中往往又是最常见的。
大多数比较复杂的应用至少应该有“菜单”和“采集”两个状态，如果数据采集程序在运行时仍然希望系统能够处理菜单的事件，这是在传统的状态机或者事件结构中无法实现的。
因为无论是状态机结构还是事件结构，都是由一个循环组成的，不同的状态是无法同时被响应和处理的。
解决这个问题的方式也比较简单，LabVIEW本身就是一种多线程的程序设计语言，可以再加一个循环或者另外开一个程序独立运行。
但是这样也会带来一些新的问题，比如：(1) 两个循环（程序）之间如何交换和共享数据。
(2) 两个循环（程序）都有着独立的错误处理系统，它们之间是如何协调的。
(3) 两个循环如何分工呢？应该以哪种方式对状态进行分类以将不同的状态放置在不同的循环（程序）中？(4) 一个程序如何控制另一个程序的运行和停止。
在上面提出的4个问题中，对循环和程序这两个解决方案而言，第（1）~（3）个问题的解决方式是一样的。
只有第（4）个问题是专门针对两个程序而言的，在LabVIEW中这种不同程序之间的相互调用称为“程序的动态调用”。
生产者/消费者模式(2)_VI的可重入性（Reentrant Execution）statemice的LabVIEW程序设计模式(五)—生产者/消费者模式(2)_VI的可重入性（Reentrant Execution）在介绍VI的动态调用之前有必要对LabVIEW在执行VI过程中的规则有个大致的了解。
众所周知，LabVIEW是通过VI的文件名（VI Name）来表示独立的VI的，并不是VI的路径。
因此，LabVIEW不允许具有相同名字的VI同时载入内存中，即使这些VI存储在不同的路径中。
LabVIEW程序设计模式(五)—生产者消费者模式(4)_生产者消费者循环
LabVIEW程序设计模式(五)—生产者/消费者模式(4)_生产者/消费者循环本节将使用“多循环”来解决程序并行运行的问题，那么程序中的两个循环如何进行数据交互和共享呢？最普通的方式是采用全局变量或局域变量，但是当两个循环执行的速率不相等时，必然会造成数据的丢失或重复。
如前所述，LabVIEW提供了队列操作函数，允许数据的发送者和接受者之间建立一条缓冲通道，这样就避免了循环不同步带来的影响。
如图37所示，将整个过程与供水系统进行类比，在数据产生/采集端（供水局）产生数据后，并不直接向终端用户供水，因为前者产生水的速率与后者消耗水的速率并不相同。
此时需要建造蓄水池将供水局产生的水放入到蓄水池中，同理获取的数据也放入该缓冲区中。
当终端用户需要用水时，直接从蓄水池中获取就可以了，同理在进行数据显示和分析时直接从数据缓冲区中获取就可以了。
图37 生产者/消费者模型当然，上面的模型也会存在一个问题：数据缓冲区/蓄水池的容量？假定供水局不停地产生自来水，而终端用户却不消耗水，这样便会导致蓄水池装满而溢出。
反之当终端用户耗水量太大时，导致没有水可用。
LabVIEW中的队列函数提供了一种很好的方式规避了这个问题，由于队列中的元素是“先进先出”的，因此确保了接收到的数据是有序的。
在LabVIEW的队列操作中（入列和出列函数），提供了timeout选项以处理数据缓冲区的溢出或不足。
当数据溢出时，入列函数（数据进入队列）将停止发送数据（处于等待状态），直到缓冲区存在数据空间或者达到了timeout设置的时间；而当数据不足时，出列函数（数据流出队列）将停止接收数据（处于等到状态），直到缓冲区进入了新的数据或者达到了timeout设置的时间。
【应用6】本例将演示生产者/消费者循环的一些基本特性和队列操作的特点。
如图38所示，生产者与消费者之间传递的数据是一个连续的sine波形，二者靠大小为20个点的缓冲区连接。
右下角是“停止”按钮，用户控制程序的停止执行。
kafka的基本概念和架构
kafka的基本概念和架构Kafka是一种分布式的流式处理平台，可以用于高吞吐量、可持久化的发布和订阅消息系统。
它具有以下的基本概念和架构：1. Topic（主题）：消息在Kafka中按照主题进行分类，每个主题可以有多个订阅者，也可以有多个生产者。
2. Partition（分区）：每个主题可以被分为多个分区，每个分区有一个唯一的标识符，消息被写入分区并按照顺序存储，而不同分区之间的消息顺序不保证。
3. Producer（生产者）：生产者负责将消息发布到指定的主题，可以选择将消息发布到指定分区或者由Kafka自动选择一个分区。
4. Consumer（消费者）：消费者负责订阅一个或多个主题，读取其中的消息。
每个消费者组可以有多个消费者实例，每个实例只能消费一个分区的消息。
5. Broker（代理）：Kafka集群由多个代理组成，每个代理都是一个独立的Kafka服务器。
代理负责处理生产者和消费者的请求，以及数据的存储和复制。
6. Consumer Group（消费者组）：消费者可以组成一个组，并共同消费一个主题的消息。
每个消息只能被同一个消费者组中的一个消费者实例消费，这样可以实现消息的负载均衡和高可用性。
7. Replication（复制）：Kafka使用复制来提供数据的容错性和可靠性。
每个主题可以配置多个副本，副本分布在不同的代理上。
当一个代理发生故障时，副本可以接管工作，保证数据的可用性。
Kafka的架构由多个生产者、多个代理以及多个消费者组成，生产者将消息发布到指定主题的分区，消费者从指定主题的分区中消费消息。
代理负责存储和复制消息，并处理生产者和消费者的请求。
通过这种方式，Kafka实现了高吞吐量、持久化和可靠性的分布式流式处理。
架构模式的实践案例分析
架构模式的实践案例分析随着科技的不断进步和应用的广泛推广，软件架构设计变得愈发重要。
在众多架构模式中，每一种都有其独特的应用场景和优缺点。
本文将通过对一些常见的架构模式的实践案例进行分析，探讨它们在实际项目中的应用情况以及其效果。
一、客户端-服务器模式1. 简介客户端-服务器模式是最常见的架构模式之一，它将应用程序分为两个独立的部分：客户端和服务器。
客户端负责用户界面和用户交互，而服务器则负责处理和存储数据。
2. 实践案例假设我们要开发一个在线购物网站，客户端通过浏览器与服务器进行通信。
用户在浏览器中输入地址后，服务器接收到请求并将网页内容返回给客户端，然后客户端显示在用户的浏览器中。
当用户点击某个商品并下订单时，客户端将订单信息发送给服务器进行处理和存储。
3. 结果与评价客户端-服务器模式的好处在于明确的角色划分，使得开发人员可以分别关注客户端和服务器的开发。
客户端可以通过各种设备访问服务器，例如电脑、手机等。
而且服务器可以进行扩展和分布式部署，提高系统的性能和响应能力。
二、发布-订阅模式1. 简介发布-订阅模式是一种松散耦合的架构模式，其中发布者（或生产者）将消息发送到某个中心，而订阅者（或消费者）注册并接收感兴趣的消息。
2. 实践案例考虑一个新闻发布系统，新闻发布者将新闻发布到消息中心，而订阅者可以选择订阅自己感兴趣的新闻类别，只接收到相关的新闻。
同时，订阅者也可以取消订阅或更改订阅偏好。
3. 结果与评价发布-订阅模式实现了解耦合和灵活性，发布者和订阅者互不依赖，可以独立进行扩展和维护。
此外，可以根据需要动态添加或移除发布者和订阅者，提高了系统的可拓展性。
三、分层架构模式1. 简介分层架构模式将应用程序划分为多个层次，每个层次各司其职，有明确定义的接口进行通信。
常见的分层包括表示层、业务逻辑层和数据访问层。
2. 实践案例假设我们正在开发一个银行系统，表示层负责用户界面的展示和用户交互，业务逻辑层处理具体的业务逻辑，例如账户管理和转账操作，数据访问层则负责与数据库进行交互。
消息传递架构的实现方法
消息传递架构的实现方法随着互联网技术不断发展，人们可以轻松地与世界各地的人进行交流和互动。
这使得信息传递变得更加直接和有效。
在这种情况下，建立一个高效的消息传递架构变得尤为重要。
本文将深入探讨消息传递架构的实现方法。
1. 定义消息传递架构消息传递架构是一个基于互联网通信的分布式系统。
它可以在不同的分布式节点之间传递消息。
消息传递架构的主要组成部分包括消息生产者、消息消费者和消息中间件。
2. 消息生产者消息生产者是负责生产消息并发布到消息中间件的组件。
消息可以是文本、图片、视频、音频等类型。
消息生产者使用消息发布协议将消息发送到消息中间件中，并使用指定的主题（Topic）将消息分类，以便消费者订阅感兴趣的消息。
3. 消息消费者消息消费者是负责从消息中间件中订阅消息并处理消息的组件。
与消息生产者不同，消息消费者不能直接从消息中间件中获取消息，而是必须使用消息订阅协议来请求并接收消息。
消费者可以订阅一个或多个主题，并在消息中间件中等待消息到达。
一旦有新消息到达，消息消费者就会触发相应的处理逻辑。
4. 消息中间件消息中间件是消息生产者和消息消费者之间的中介。
它负责接收、存储和转发消息。
消息中间件通常采用队列和订阅模式进行消息传输。
队列模式是一种点对点的模型，其中消息生产者将消息发布到队列中，只有一个消息消费者能够接收并处理这个消息。
订阅模式是一种发布-订阅的模型，其中消息生产者将消息发布到主题（Topic）中，多个消息消费者可以订阅主题并接收相应的消息。
5. 实现方法实现消息传递架构有多种方法。
下面将介绍两种常见的实现方法。
1) 基于JMS（Java消息服务）实现JMS是Java语言规范中定义的一种API，用于在Java应用程序之间传递消息。
JMS提供了一套标准的API和协议，以实现Java 应用程序之间的消息传递。
目前，许多消息中间件都支持JMS协议，因此JMS被广泛用于实现消息传递架构。
2) 基于AMQP（高级消息队列协议）实现AMQP是一种开放的消息传递协议，支持多种编程语言和消息中间件。
labview生产者消费者
生产者/消费者模式(1)_前言statemice的LabVIEW程序设计模式(五)—生产者/消费者模式(1)_前言再次回顾“基本状态机模式”的6个缺点，只剩下第6个缺点无法在上述的“状态机和事件结构的结合模式”中被解决。
(1) 任何时刻只能有一个状态在运行这个问题也许有些多余，但是在实际的应用中往往又是最常见的。
大多数比较复杂的应用至少应该有“菜单”和“采集”两个状态，如果数据采集程序在运行时仍然希望系统能够处理菜单的事件，这是在传统的状态机或者事件结构中无法实现的。
因为无论是状态机结构还是事件结构，都是由一个循环组成的，不同的状态是无法同时被响应和处理的。
解决这个问题的方式也比较简单，LabVIEW本身就是一种多线程的程序设计语言，可以再加一个循环或者另外开一个程序独立运行。
但是这样也会带来一些新的问题，比如：(1) 两个循环（程序）之间如何交换和共享数据。
(2) 两个循环（程序）都有着独立的错误处理系统，它们之间是如何协调的。
(3) 两个循环如何分工呢？应该以哪种方式对状态进行分类以将不同的状态放置在不同的循环（程序）中？(4) 一个程序如何控制另一个程序的运行和停止。
在上面提出的4个问题中，对循环和程序这两个解决方案而言，第（1）~（3）个问题的解决方式是一样的。
只有第（4）个问题是专门针对两个程序而言的，在LabVIEW中这种不同程序之间的相互调用称为“程序的动态调用”。
生产者/消费者模式(2)_VI的可重入性（Reentrant Execution）statemice的LabVIEW程序设计模式(五)—生产者/消费者模式(2)_VI的可重入性（Reentrant Execution）在介绍VI的动态调用之前有必要对LabVIEW在执行VI过程中的规则有个大致的了解。
众所周知，LabVIEW是通过VI的文件名（VI Name）来表示独立的VI的，并不是VI的路径。
因此，LabVIEW不允许具有相同名字的VI同时载入内存中，即使这些VI存储在不同的路径中。
producer consumer 设计模式
producer consumer 设计模式生产者消费者设计模式是一种多线程设计模式，用于解决生产者和消费者之间的同步和通信问题。
此设计模式基于一个共享缓冲区，生产者向缓冲区中放入数据，消费者从缓冲区中取出数据。
此设计模式能够保证生产者和消费者的同步，避免生产者在缓冲区已满时继续生产，消费者在缓冲区为空时继续消费的问题。
在生产者消费者设计模式中，有以下几个核心角色：1. 生产者：负责生成数据，并将数据放入缓冲区。
2. 消费者：负责从缓冲区中取出数据并进行消费。
3. 缓冲区：共享的数据结构，用于存储生产者生成的数据，以及供消费者取出的数据。
4. 消费者队列：一个队列用于存放等待消费者消费的数据。
5. 信号量：用于控制生产者和消费者的访问权限。
当缓冲区已满时，生产者需要等待信号量；而当缓冲区为空时，消费者需要等待信号量。
6. 锁：用于确保同时只有一个线程能够访问共享资源。
以下是生产者消费者设计模式的基本实现步骤：1. 初始化缓冲区、信号量和锁。
2. 创建生产者线程和消费者线程，并启动它们。
3. 生产者线程生成数据，并将数据放入缓冲区。
如果缓冲区已满，生产者线程会等待信号量。
4. 消费者线程从缓冲区中取出数据并进行消费。
如果缓冲区为空，消费者线程会等待信号量。
5. 当生产者线程将数据放入缓冲区后，释放信号量，允许消费者线程继续。
6. 当消费者线程从缓冲区中取出数据后，释放信号量，允许生产者线程继续。
通过使用生产者消费者设计模式，可以有效地解决多线程环境下的数据同步和通信问题，确保生产者和消费者之间的合作顺利进行。
labview主／从设计模式和生产者／消费者设计模式
5.2LabVIEW设计模式——主／从设计模式和生产者／消费者设计模式在上一节中曾经谈到过，NI LabVIEW中提供了六种最基本的设计模式。
本节首先介绍其中的两种：主／从设计模式与生产者／消费者设计模式（Master/Slave design pattern and Producer/Consumer design pattern）。
这是由于这两种设计模式在结构上极为相似（使用的内置函数不同），所以我们在这里将一起来讨论（基本结构参见图5.2-1、图5.2-2）。
图5.2-1主／从设计模式图5.2-2生产者／消费者设计模式5.2.1主／从设计模式（Master/Slave design pattern）与主／从设计模式的相关内置函数（Notifier_通知）参见下图所示。
图5.2.1-1主／从设计模式内置函数（通知）关于这些内置函数的定义和使用方法请参考LabVIEW Help文件，这里就不再进行讨论了。
对于绝大多数LabVIEW的学习者来讲，仅仅依据这些主／从操作提供的内置函数（通知），即便是借助于帮助文件也很难理解和设计出正确的应用程序代码或基本架构。
因为这些内置函数的内部程序代码是不对外开放的、不公开的，所以我们也就很难理解的更准确或更全面。
那么如何正确的使用它们呢？通常有两个最简单、最直接的方法可以解决这个问题：一是，查看NI给出的设计模式或例程；二是，查看其它使用者所提供的实用例程。
其实，这里也再次间接的告诉大家，更多查看和理解其它LabVIEW开好者所提供的实用例程是学习LabVIEW的最好方法之一。
通过图5.2-1，就可以初略地领会到NI基于数据流的图形化代码主／从设计模式的表达形式或架构。
从图5.2-1中，可以看到主／从设计模式的基本构成是：包括了两个While循环（上面为主循环、下面的为从循环）和若干个“通知”内置函数（Notifier）构成。
主循环中的Case结构用来确定是否向从循环发出通知。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
架构设计：生产者/消费者模式为了方便阅读，把本系列帖子的目录整理如下：0、概述1、如何确定数据单元2、队列缓冲区3、环形缓冲区4、双缓冲区[0]：概述今天打算来介绍一下“生产者／消费者模式”，这玩意儿在很多开发领域都能派上用场。
由于该模式很重要，打算分几个帖子来介绍。
今天这个帖子先来扫盲一把。
如果你对这个模式已经比较了解，请跳过本扫盲帖，直接看下一个帖子（关于该模式的具体应用）。
看到这里，可能有同学心中犯嘀咕了：在四人帮（GOF）的23种模式里面似乎没听说过这种嘛！其实GOF那经典的23种模式主要是基于OO的（从书名《Design Patterns: Elements of Reusable Object-Oriented Software》就可以看出来）。
而Pattern实际上即可以是OO的Pattern，也可以是非OO的Pattern的。
★简介言归正传！在实际的软件开发过程中，经常会碰到如下场景：某个模块负责产生数据，这些数据由另一个模块来负责处理（此处的模块是广义的，可以是类、函数、线程、进程等）。
产生数据的模块，就形象地称为生产者；而处理数据的模块，就称为消费者。
单单抽象出生产者和消费者，还够不上是生产者／消费者模式。
该模式还需要有一个缓冲区处于生产者和消费者之间，作为一个中介。
生产者把数据放入缓冲区，而消费者从缓冲区取出数据。
大概的结构如下图。
为了不至于太抽象，我们举一个寄信的例子（虽说这年头寄信已经不时兴，但这个例子还是比较贴切的）。
假设你要寄一封平信，大致过程如下：1、你把信写好——相当于生产者制造数据2、你把信放入邮筒——相当于生产者把数据放入缓冲区3、邮递员把信从邮筒取出——相当于消费者把数据取出缓冲区4、邮递员把信拿去邮局做相应的处理——相当于消费者处理数据★优点可能有同学会问了：这个缓冲区有什么用捏？为什么不让生产者直接调用消费者的某个函数，直接把数据传递过去？搞出这么一个缓冲区作甚？其实这里面是大有讲究的，大概有如下一些好处。
◇解耦假设生产者和消费者分别是两个类。
如果让生产者直接调用消费者的某个方法，那么生产者对于消费者就会产生依赖（也就是耦合）。
将来如果消费者的代码发生变化，可能会影响到生产者。
而如果两者都依赖于某个缓冲区，两者之间不直接依赖，耦合也就相应降低了。
接着上述的例子，如果不使用邮筒（也就是缓冲区），你必须得把信直接交给邮递员。
有同学会说，直接给邮递员不是挺简单的嘛？其实不简单，你必须得认识谁是邮递员，才能把信给他（光凭身上穿的制服，万一有人假冒，就惨了）。
这就产生和你和邮递员之间的依赖（相当于生产者和消费者的强耦合）。
万一哪天邮递员换人了，你还要重新认识一下（相当于消费者变化导致修改生产者代码）。
而邮筒相对来说比较固定，你依赖它的成本就比较低（相当于和缓冲区之间的弱耦合）。
◇支持并发（concurrency）生产者直接调用消费者的某个方法，还有另一个弊端。
由于函数调用是同步的（或者叫阻塞的），在消费者的方法没有返回之前，生产者只好一直等在那边。
万一消费者处理数据很慢，生产者就会白白糟蹋大好时光。
使用了生产者／消费者模式之后，生产者和消费者可以是两个独立的并发主体（常见并发类型有进程和线程两种，后面的帖子会讲两种并发类型下的应用）。
生产者把制造出来的数据往缓冲区一丢，就可以再去生产下一个数据。
基本上不用依赖消费者的处理速度。
其实当初这个模式，主要就是用来处理并发问题的。
从寄信的例子来看。
如果没有邮筒，你得拿着信傻站在路口等邮递员过来收（相当于生产者阻塞）；又或者邮递员得挨家挨户问，谁要寄信（相当于消费者轮询）。
不管是哪种方法，都挺土的。
◇支持忙闲不均缓冲区还有另一个好处。
如果制造数据的速度时快时慢，缓冲区的好处就体现出来了。
当数据制造快的时候，消费者来不及处理，未处理的数据可以暂时存在缓冲区中。
等生产者的制造速度慢下来，消费者再慢慢处理掉。
为了充分复用，我们再拿寄信的例子来说事。
假设邮递员一次只能带走1000封信。
万一某次碰上情人节（也可能是圣诞节）送贺卡，需要寄出去的信超过1000封，这时候邮筒这个缓冲区就派上用场了。
邮递员把来不及带走的信暂存在邮筒中，等下次过来时再拿走。
费了这么多口水，希望原先不太了解生产者／消费者模式的同学能够明白它是怎么一回事。
然后在下一个帖子中，我们来说说如何确定数据单元。
[1]：如何确定数据单元？既然前一个帖子已经搞过扫盲了，那接下来应该开始聊一些具体的编程技术问题了。
不过在进入具体的技术细节之前，咱们先要搞明白一个问题：如何确定数据单元？只有把数据单元分析清楚，后面的技术设计才好搞。
★啥是数据单元何谓数据单元捏？简单地说，每次生产者放到缓冲区的，就是一个数据单元；每次消费者从缓冲区取出的，也是一个数据单元。
对于前一个帖子中寄信的例子，我们可以把每一封单独的信件看成是一个数据单元。
不过光这么介绍，太过于简单，无助于大伙儿分析出这玩意儿。
所以，后面咱们来看一下数据单元需要具备哪些特性。
搞明白这些特性之后，就容易从复杂的业务逻辑中分析出适合做数据单元的东西了。
★数据单元的特性分析数据单元，需要考虑如下几个方面的特性：◇关联到业务对象首先，数据单元必须关联到某种业务对象。
在考虑该问题的时候，你必须深刻理解当前这个生产者／消费者模式所对应的业务逻辑，才能够作出合适的判断。
由于“寄信”这个业务逻辑比较简单，所以大伙儿很容易就可以判断出数据单元是啥。
但现实生活中，往往没这么乐观。
大多数业务逻辑都比较复杂，当中包含的业务对象是层次繁多、类型各异。
在这种情况下，就不易作出决策了。
这一步很重要，如果选错了业务对象，会导致后续程序设计和编码实现的复杂度大为上升，增加了开发和维护成本。
◇完整性所谓完整性，就是在传输过程中，要保证该数据单元的完整。
要么整个数据单元被传递到消费者，要么完全没有传递到消费者。
不允许出现部分传递的情形。
对于寄信来说，你不能把半封信放入邮筒；同样的，邮递员从邮筒中拿信，也不能只拿出信的一部分。
◇独立性所谓独立性，就是各个数据单元之间没有互相依赖，某个数据单元传输失败不应该影响已经完成传输的单元；也不应该影响尚未传输的单元。
为啥会出现传输失败捏？假如生产者的生产速度在一段时间内一直超过消费者的处理速度，那就会导致缓冲区不断增长并达到上限，之后的数据单元就会被丢弃。
如果数据单元相互独立，等到生产者的速度降下来之后，后续的数据单元继续处理，不会受到牵连；反之，如果数据单元之间有某种耦合，导致被丢弃的数据单元会影响到后续其它单元的处理，那就会使程序逻辑变得非常复杂。
对于寄信来说，某封信弄丢了，不会影响后续信件的送达；当然更不会影响已经送达的信件。
◇颗粒度前面提到，数据单元需要关联到某种业务对象。
那么数据单元和业务对象是否要一一对应捏？很多场合确实是一一对应的。
不过，有时出于性能等因素的考虑，也可能会把N个业务对象打包成一个数据单元。
那么，这个N该如何取值就是颗粒度的考虑了。
颗粒度的大小是有讲究的。
太大的颗粒度可能会造成某种浪费；太小的颗粒度可能会造成性能问题。
颗粒度的权衡要基于多方面的因素，以及一些经验值的考量。
还是拿寄信的例子。
如果颗粒度过小（比如设定为1），那邮递员每次只取出1封信。
如果信件多了，那就得来回跑好多趟，浪费了时间。
如果颗粒度太大（比如设定为100），那寄信的人得等到凑满100封信才拿去放入邮筒。
假如平时很少写信，就得等上很久，也不太爽。
可能有同学会问：生产者和消费者的颗粒度能否设置成不同大小（比如对于寄信人设置成1，对于邮递员设置成100）。
当然，理论上可以这么干，但是在某些情况下会增加程序逻辑和代码实现的复杂度。
后面讨论具体技术细节时，或许会聊到这个问题。
好，数据单元的话题就说到这。
希望通过本帖子，大伙儿能够搞明白数据单元到底是怎么一回事。
下一个帖子，咱们来聊一下“基于队列的缓冲区”，技术上如何实现。
[2]：队列缓冲区经过前面两个帖子的铺垫，今天终于开始聊一些具体的编程技术了。
由于不同的缓冲区类型、不同的并发场景对于具体的技术实现有较大的影响。
为了深入浅出、便于大伙儿理解，咱们先来介绍最传统、最常见的方式。
也就是单个生产者对应单个消费者，当中用队列（FIFO）作缓冲。
关于并发的场景，在之前的帖子“进程还线程？是一个问题！”中，已经专门论述了进程和线程各自的优缺点，两者皆不可偏废。
所以，后面对各种缓冲区类型的介绍都会同时提及进程方式和线程方式。
★线程方式先来说一下并发线程中使用队列的例子，以及相关的优缺点。
◇内存分配的性能在线程方式下，生产者和消费者各自是一个线程。
生产者把数据写入队列头（以下简称push），消费者从队列尾部读出数据（以下简称pop）。
当队列为空，消费者就稍息（稍事休息）；当队列满（达到最大长度），生产者就稍息。
整个流程并不复杂。
那么，上述过程会有什么问题捏？一个主要的问题是关于内存分配的性能开销。
对于常见的队列实现：在每次push时，可能涉及到堆内存的分配；在每次pop时，可能涉及堆内存的释放。
假如生产者和消费者都很勤快，频繁地push、pop，那内存分配的开销就很可观了。
对于内存分配的开销，用Java的同学可以参见前几天的帖子“Java性能优化[1]”；对于用C/C++的同学，想必对OS 底层机制会更清楚，应该知道分配堆内存（new或malloc）会有加锁的开销和用户态／核心态切换的开销。
那该怎么办捏？请听下文分解，关于“生产者／消费者模式[3]：环形缓冲区”。
◇同步和互斥的性能另外，由于两个线程共用一个队列，自然就会涉及到线程间诸如同步啊、互斥啊、死锁啊等等劳心费神的事情。
好在"操作系统"这门课程对此有详细介绍，学过的同学应该还有点印象吧？对于没学过这门课的同学，也不必难过，网上相关的介绍挺多的（比如"这里"），大伙自己去瞅一瞅。
关于这方面的细节，咱今天就不多啰嗦了。
这会儿要细谈的是，同步和互斥的性能开销。
在很多场合中，诸如信号量、互斥量等玩意儿的使用也是有不小的开销的（某些情况下，也可能导致用户态／核心态切换）。
如果像刚才所说，生产者和消费者都很勤快，那这些开销也不容小觑啊。
这又该咋办捏？请听下文的下文分解，关于“生产者／消费者模式[4]：双缓冲区”。
◇适用于队列的场合刚才尽批判了队列的缺点，难道队列方式就一无是处？非也。
由于队列是很常见的数据结构，大部分编程语言都内置了队列的支持（具体介绍见"这里"），有些语言甚至提供了线程安全的队列（比如JDK 1.5引入的ArrayBlockingQueue）。
因此，开发人员可以捡现成，避免了重新发明轮子。
所以，假如你的数据流量不是很大，采用队列缓冲区的好处还是很明显的：逻辑清晰、代码简单、维护方便。