Java 生产者消费者模式
简介
生产者消费者模式并不是GOF提出的23种设计模式之一，23中设计模式是建立在面向对象的基础上的，但其实面向过程的编程中也有很多高校的编程模式，生产者消费者模式便是其中之一，它是我们编程过程中最常用的一种设计模式。
在实际的软件开发中，经常会碰到如下场景：某个模块负责产生数据，这些数据由另一个模块来负责处理。产生数据的模块，就形象地称为生产者，而处理数据的模块，就称为消费者。
单单抽象出生产者和消费者，还不够称之为生产者消费者模式。该模式还需要有一个缓冲区处于生产者金额消费者之间，作为一个中介，生产者把数据放入缓冲区，而消费者从缓冲区取出数据，大概的结构图如下图：
在网上有一个很好的例子：就是寄信，假设你要寄一封信，那么大致过程如下：
1.首先，你要把信写好-------------------相当于生产者制造数据
2.你要把写好的信放在邮筒--------------------相当于生产者把数据放入缓冲区
3.邮递员把信从信箱取出---------------------相当于消费者把数据去除缓冲区
4.邮递员把信拿去邮局做相应的处理----------------相当于消费者处理数据
优点
1.解耦
假设生产者消费者分别是两个类，如果让生产者直接调用消费者的某个方法，那么生产者对于消费者就会产生依赖。将来如果消费者的代码改变，可能会影响到生产者。而如果两个类都依赖于某个缓冲区，两者之间不直接依赖，那么耦合也就降低了。
2.支持并发(concurrency)
生产者直接调用消费者的某个方法，还有另一个弊端，就是函数调用是同步的，或者叫阻塞的，如果不清楚概念可以去找找多线程基础，如果多线程情况下，生产者调用了消费者的方法，那么如果消费者的方法在没有返回之前，那么生产者就只好一直等在那边队列。网易消费者处理数据很慢，生产者就一直在那等，很浪费时间。
如果使用了生产者消费者模式，那么生产者和消费者是两个独立的并发主体，生产者就没有直接依赖于消费者，而是生产者直接把制造出来的数据往缓存区一丢，他就可以接着去生成下一个数据，基本上不用依赖消费者的处理速度。
3.支持忙闲不均
缓冲区还有另一个好处。如果制造数据的速度时快时慢，缓冲区的好处就体现出来了，当数据制造快的时候，消费者来不及处理，未处理的数据可以暂时存在缓冲区中，等生产者的制造速度慢下来后，消费者在慢慢处理掉。
数据单元
什么是数据单元，简单来说，每次生产者放放到缓冲区，就是一个数据单元，每次消费者从缓冲区取出的，也是一个数据单元。
数据单元的特性：
1.关联到业务对象：首先，数据单元必须关联某种业务对象
2.完整性：所谓完整性，就是在数据单元传输的过程中，要保证数据单元的完整性，要么整个数据单元传递给消费者，要么完全没有传递给消费者。不允许出现部分传递这种。
3.独立性：所谓独立性，就是各个数据单元之间没有互相依赖，某个数据单元传输失败不影响已经传输成功的单元，也不影响还未传输的单元。
4.颗粒度：有时候处于性能等因素的考虑，也可能会把N个业务对象打包成一个数据单元，那么，这个N该如何取值就是颗粒度的考虑了。颗粒度的大小是有讲究的。太大的颗粒度可能会造成某种浪费；太小的颗粒度可能会造成性能问题。颗粒度的权衡要基于多方面的因素，以及一些经验值的考量。
队列缓冲区
不同的缓冲区技术，不同的并发场景对于具体的技术野是有较大的影响，现在我们先来看最传统也最常用的方式。也就是单个生产者单个消费者说起，当中用队列（FIFO）作为缓冲。
线程方式
- 在线程方式下，生产者和消费者各自是一个线程。生产者把数据写入队列头（以下简称push），消费者从队列尾部读出数据（以下简称pop）。当队列为空，消费者就稍息（稍事休息）；当队列满（达到最大长度），生产者就稍息。整个流程并不复杂。
那么，上述过程会有什么问题捏？一个主要的问题是关于内存分配的性能开销。对于常见的队列实现：在每次push时，可能涉及到堆内存的分配；在每次pop时，可能涉及堆内存的释放。假如生产者和消费者都很勤快，频繁地push、pop，那内存分配的开销就很可观了。
2.同步和互斥的性能：另外由于是多线程，然后就会设计到线程间的一些问题，例如同步，互斥，死锁等等。同步和互斥的性能开销。在很多场合中，诸如信号量、互斥量等玩意儿的使用也是有不小的开销的（某些情况下，也可能导致用户态／核心态切换）。如果像刚才所说，生产者和消费者都很勤快，那这些开销也不容小觑啊。这个问题我们可以使用生产者消费者模式的双缓冲区来解决。
3.上面两点说了队列的缺点，但是队列也有很多优点：由于队列是很常见的数据结构，大部分编程语言都内置了队列的支持，有些语言甚至提供了线程安全的队列（比如JDK 1.5引入的ArrayBlockingQueue）。因此，开发人员可以捡现成，避免了重新发明轮子。
所以，假如你的数据流量不是很大，采用队列缓冲区的好处还是很明显的：逻辑清晰、代码简单、维护方便。比较符合KISS原则。
进程方式
跨进程的生产者／消费者模式，非常依赖于具体的进程间通讯（IPC）方式。而IPC的种类名目繁多，因此咱们挑选几种跨平台、且编程语言支持较多的IPC方式来说。
1.匿名管道：管道其实是最想队列的IPC类型，生产者进程仔管道的写端放入数据，消费者仔管道的读端读取数据，震哥哥的效果和线程中使用队列十分相似，区别在于使用管道就无需担心线程安全。
管道又分命名管道和匿名管道两种，今天主要聊匿名管道。因为命名管道在不同的操作系统下差异较大（比如Win32和POSIX，在命名管道的API接口和功能实现上都有较大差异；有些平台不支持命名管道，比如Windows CE）。除了操作系统的问题，对于有些编程语言（比如Java）来说，命名管道是无法使用的。所以我一般不推荐。
其实匿名管道在不同平台上的API接口，也是有差异的（比如Win32的CreatePipe和POSIX的pipe，用法就很不一样）。但是我们可以仅使用标准输入和标准输出（以下简称stdio）来进行数据的流入流出。然后利用shell的管道符把生产者进程和消费者进程关联起来
这么干有几个好处：
1、基本上所有操作系统都支持在shell方式下使用管道符。因此很容易实现跨平台。
2、大部分编程语言都能够操作stdio，因此跨编程语言也就容易实现。
3、刚才已经提到，管道方式省却了线程安全方面的琐事。有利于降低开发、调试成本。
当然，这种方式也有自身的缺点：
1、生产者进程和消费者进程必须得在同一台主机上，无法跨机器通讯。这个缺点比较明显。
2、在一对一的情况下，这种方式挺合用。但如果要扩展到一对多或者多对一，那就有点棘手了。所以这种方式的扩展性要打个折扣。假如今后要考虑类似的扩展，这个缺点就比较明显。
3、由于管道是shell创建的，对于两边的进程不可见（程序看到的只是stdio）。在某些情况下，导致程序不便于对管道进行操纵（比如调整管道缓冲区尺寸）。这个缺点不太明显。
4、最后，这种方式只能单向传数据。好在大多数情况下，消费者进程不需要传数据给生产者进程。万一你确实需要信息反馈（从消费者到生产者），那就费劲了。可能得考虑换种IPC方式。
顺便补充几个注意事项，大伙儿留意一下：
1、对stdio进行读写操作是以阻塞方式进行。比如管道中没有数据，消费者进程的读操作就会一直停在哪儿，直到管道中重新有数据。
2、由于stdio内部带有自己的缓冲区（这缓冲区和管道缓冲区是两码事），有时会导致一些不太爽的现象（比如生产者进程输出了数据，但消费者进程没有立即读到）。具体的细节，大伙儿可以看"这里"。
SOCKET(TCP方式)
基于TCP方式的SOCKET通讯是又一个类似于队列的IPC方式。它同样保证了数据的顺序到达；同样有缓冲的机制。而且这玩意儿也是跨平台和跨语言的，和刚才介绍的shell管道符方式类似。
SOCKET相比shell管道符的方式，有啥优点捏？主要有如下几个优点：
1、SOCKET方式可以跨机器（便于实现分布式）。这是主要优点。
2、SOCKET方式便于将来扩展成为多对一或者一对多。这也是主要优点。
3、SOCKET可以设置阻塞和非阻塞方法，用起来比较灵活。这是次要优点。
4、SOCKET支持双向通讯，有利于消费者反馈信息。
当然有利就有弊。相对于上述shell管道的方式，使用SOCKET在编程上会更复杂一些。好在前人已经做了大量的工作，搞出很多SOCKET通讯库和框架给大伙儿用（比如C++的ACE库、Python的Twisted）。借助于这些第三方的库和框架，SOCKET方式用起来还是比较爽的。由于具体的网络通讯库该怎么用不是本系列的重点，此处就不细说了。
虽然TCP在很多方面比UDP可靠，但鉴于跨机器通讯先天的不可预料性（比如网线可能被某傻X给拔错了，网络的忙闲波动可能很大），在程序设计上我们还是要多留一手。具体该如何做捏？可以在生产者进程和消费者进程内部各自再引入基于线程的"生产者／消费者模式"。如下图所示：
这么做的关键点在于把代码分为两部分：生产线程和消费线程属于和业务逻辑相关的代码（和通讯逻辑无关）；发送线程和接收线程属于通讯相关的代码（和业务逻辑无关）。
这样的好处是很明显的，具体如下：
1、能够应对暂时性的网络故障。并且在网络故障解除后，能够继续工作。
2、网络故障的应对处理方式（比如断开后的尝试重连），只影响发送和接收线程，不会影响生产线程和消费线程（业务逻辑部分）。
3、具体的SOCKET方式（阻塞和非阻塞）只影响发送和接收线程，不影响生产线程和消费线程（业务逻辑部分）。
4、不依赖TCP自身的发送缓冲区和接收缓冲区。（默认的TCP缓冲区的大小可能无法满足实际要求）
5、业务逻辑的变化（比如业务需求变更）不影响发送线程和接收线程。
针对上述的最后一条，再多啰嗦几句。如果整个业务系统中有多个进程是采用上述的模式，那或许可以重构一把：在业务逻辑代码和通讯逻辑代码之间切一刀，把业务逻辑无关的部分封装成一个通讯中间件。
环形缓冲区
只有当存储空间的分配或者释放非常频繁并且确实产生了明显的影响，你才应该考虑环形缓冲区。
环形缓冲区 vs队列缓冲区
1.外部接口相似：普通的队列缓也有一个写入段一个读出端，当队列为空，读出端无法读取数据，当队列满时，写入端无法写入数据。
环形缓冲区也是一样的，也有一个写入端(用于push)，和一个读出端(pop)，也有缓冲区满和空的状态。所以从队列缓冲区切换到环形缓冲区对于使用者来说并不难。
2.内部结构迥异：虽然说两者的对外接口差不多，但是内部结构和运作机制差别就很大了，这里重点说一下环形缓冲区的内部结构。
我们可以把环形缓冲区想象成一个圆形的操场，里面有两个人，一个是生产者一个是消费者，生产者在前，消费者在后，生产者一直绕着操场生产，而消费者就在后面一直使用。如果说消费者追上了生产者，，那么这个操场上就没有生产者生产的了，也就是说缓存区是空的，反之，如果生产者生产速度很快追上了在后面的消费者的话，那么就证明了缓存区已经被生产者生产满了。如下图所示：
从上图可以看出，环形缓冲区所有的push和pop操作都是在一个固定的存储空间内进行。而队列缓冲区在push的时候，可能会分配存储空间用于存储新元素；在pop时，可能会释放废弃元素的存储空间。所以环形方式相比队列方式，少掉了对于缓冲区元素所用存储空间的分配、释放。这是环形缓冲区的一个主要优势。
环形缓冲区的实现
数组方式 vs 链表方式
环形缓冲区的内部实现，即可基于数组（此处的数组，泛指连续存储空间）实现，也可基于链表实现。
数组在物理存储上是一维的连续线性结构，可以在初始化时，把存储空间一次性分配好，这是数组方式的优点。但是要使用数组来模拟环，你必须在逻辑上把数组的头和尾相连。在顺序遍历数组时，对尾部元素（最后一个元素）要作一下特殊处理。访问尾部元素的下一个元素时，要重新回到头部元素（第0个元素）。如下图所示：
使用链表的方式，正好和数组相反：链表省去了头尾相连的特殊处理。但是链表在初始化的时候比较繁琐，而且在有些场合（比如后面提到的跨进程的IPC）不太方便使用。
读写操作
环形缓冲区要维护两个索引，分别对应写入端（W）和读取端（R）。写入（push）的时候，先确保环没满，然后把数据复制到W所对应的元素，最后W指向下一个元素；读取（pop）的时候，先确保环没空，然后返回R对应的元素，最后R指向下一个元素。
判断“空”和“满”
上述的操作并不复杂，不过有一个小小的麻烦：空环和满环的时候，R和W都指向同一个位置！这样就无法判断到底是“空”还是“满”。大体上有两种方法可以解决该问题。
办法1：始终保持一个元素不用
当空环的时候，R和W重叠。当W比R跑得快，追到距离R还有一个元素间隔的时候，就认为环已经满。当环内元素占用的存储空间较大的时候，这种办法显得很土（浪费空间）。
办法2：维护额外变量
如果不喜欢上述办法，还可以采用额外的变量来解决。比如可以用一个整数记录当前环中已经保存的元素个数（该整数>=0）。当R和W重叠的时候，通过该变量就可以知道是“空”还是“满”。
元素的储存
由于环形缓冲区本身就是要降低存储空间分配的开销，因此缓冲区中元素的类型要选好。尽量存储值类型的数据，而不要存储指针（引用）类型的数据。因为指针类型的数据又会引起存储空间（比如堆内存）的分配和释放，使得环形缓冲区的效果打折扣。
用于并发线程
和线程中的队列缓冲区类似，线程中的环形缓冲区也要考虑线程安全问题。除非你是用的环形缓冲区的库已经帮你实现了线程安全，否则你得自己动手搞定。
用于并发进程
进程间的环形缓冲区，似乎少有现成的库可用。那就只能自己写了。
适用于进程间环形缓冲区的IPC类型，常见的有共享内存和文件。这两种方式上进行缓冲，都是采用数组的方式实现，程序实现分配好一个固定长度的储存空间，然后具体的读写操作，判断空和满，元素储存等细节就可以照前面所说的进行。
共享内存方式的性能很好，适用于数据流量很大的场景。但是有些语言（比如Java）对于共享内存不支持。因此，该方式在多语言协同开发的系统中，会有一定的局限性。
而文件方式在编程语言方面支持很好，几乎所有编程语言都支持操作文件。但它可能会受限于磁盘读写（Disk I/O）的性能。所以文件方式不太适合于快速数据传输；但是对于某些“数据单元”很大的场合，文件方式是值得考虑的。
生产/消费问题是个非常经典的多线程问题，涉及到的对象包括“生产者”、“消费者”、“仓库”和“产品”。他们之间的关系如下：
① 生产者仅仅在仓储未满时候生产，仓满则停止生产。
② 消费者仅仅在仓储有产品时候才能消费，仓空则等待。
③ 当消费者发现仓库没产品可消费时候会通知生产者生产。
④ 生产者在生产出可消费产品时候，应该通知等待的消费者去消费。
参考：https://blog.csdn.net/u011109589/article/details/80519863