其实在c#中模拟是很简单的 因为他有了队列和栈 不用我们在去创建这样的数据结构了，
这个模式也是很简单，在我的理解下 他解决了生产者和消费这之间冲突的问题，说白了也就是多线程争抢资源的问题，一开始学习操作系统的时候对这个模式很是复杂 还设计到了信号量机制，但是现在仔细想来也没有什么必要了！
总体思路： 1. 创建一个队列 ：用来当作生产者和消费者的缓冲区，所以这个缓冲区应该是做到线程内唯一的
2. 创建两个线程 一个是生产者线程 另一个是消费者线程，做到生产者生产了物品就放到这个缓冲区中，而消费者时时刻刻可以从这个缓冲区中去拿物品，只要是有就可以拿，生产者则只要是缓冲区不满就可以往里面放，而且队列是一个先对先出的数据结构，同时他维护了枷锁的机制，这样省去了我们很多的考虑
最近在做的lucene搜索中的一个模块就用到这个模式，但是有一点不好的是队列容易造成丢包的现象，当服务器重启后队列中的数据也就玩了，所以开始的时候想的是在用一个线程时刻的去序列化队列中的数据到磁盘上，但是不知道这个线程总是自动退出，和序列化文件的时候文件思索等等问题这个功能也就放了下来，今后有时间了在思考，其实使用memercached也是可以的但是就要有这个服务器增大了开销，有时候也会想用数据库，也是一种不错的方式，可以试一下！
生产者消费者模式特点：
在工作中，大家可能会碰到这样一种情况：某个模块负责产生数据，这些数据由另一个模块来负责处理（此处的模块是广义的，可以是类、函数、线程、进程等）。产生数据的模块，就形象地称为生产者；而处理数据的模块，就称为消费者。在生产者与消费者之间在加个缓冲区，我们形象的称之为仓库，生产者负责往仓库了进商品，而消费者负责从仓库里拿商品，这就构成了生产者消费者模式。结构图如下：
生产者消费者模式的优点
1、解耦
假设生产者和消费者分别是两个类。如果让生产者直接调用消费者的某个方法，那 么生产者对于消费者就会产生依赖（也就是耦合）。将来如果消费者的代码发生变化， 可能会影响到生产者。而如果两者都依赖于某个缓冲区，两者之间不直接依赖，耦合也 就相应降低了。
举个例子，我们去邮局投递信件，如果不使用邮筒（也就是缓冲区），你必须得把 信直接交给邮递员。有同学会说，直接给邮递员不是挺简单的嘛？其实不简单，你必须 得认识谁是邮递员，才能把信给他（光凭身上穿的制服，万一有人假冒，就惨了）。这 就产生和你和邮递员之间的依赖（相当于生产者和消费者的强耦合）。万一哪天邮递员 换人了，你还要重新认识一下（相当于消费者变化导致修改生产者代码）。而邮筒相对 来说比较固定，你依赖它的成本就比较低（相当于和缓冲区之间的弱耦合）。
2、支持并发
由于生产者与消费者是两个独立的并发体，他们之间是用缓冲区作为桥梁连接，生产者只需要往缓冲区里丢数据，就可以继续生产下一个数据，而消费者只需要从缓冲区了拿数据即可，这样就不会因为彼此的处理速度而发生阻塞。
接上面的例子，如果我们不使用邮筒，我们就得在邮局等邮递员，直到他回来，我们把信件交给他，这期间我们啥事儿都不能干（也就是生产者阻塞），或者邮递员得挨家挨户问，谁要寄信（相当于消费者轮询）。
3、支持忙闲不均
缓冲区还有另一个好处。如果制造数据的速度时快时慢，缓冲区的好处就体现出来 了。当数据制造快的时候，消费者来不及处理，未处理的数据可以暂时存在缓冲区中。 等生产者的制造速度慢下来，消费者再慢慢处理掉。
为了充分复用，我们再拿寄信的例子来说事。假设邮递员一次只能带走1000封信。 万一某次碰上情人节（也可能是圣诞节）送贺卡，需要寄出去的信超过1000封，这时 候邮筒这个缓冲区就派上用场了。邮递员把来不及带走的信暂存在邮筒中，等下次过来 时再拿走。
实际应用
在P3版本升级项目中，信息服务器要接收大批量的客户端请求，原来那种串行化的 处理，根本无法及时处理客户端请求，造成信息服务器大量请求堆积，导致丢包异 常严重。之后就采用了生产者消费者模式，在业务请求与业务处理间，建立了一个List 类型的缓冲区，服务端接收到业务请求，就往里扔，然后再去接收下一个业务请求，而 多个业务处理线程，就会去缓冲区里取业务请求处理。这样就大大提高了服务器的相 应速度。