原文地址：http://ifeve.com/dissecting-disruptor-wiring-up/
作者：Trisha 译者：廖涵 校对：方腾飞
现在我已经讲了 RingBuffer 本身，如何从它 读取 以及如何向它 写入。从逻辑上来说，下一件要做的事情就是把所有的东西拼装到在一起。
我前面提到过多生产者的情况——他们通过 ProducerBarrier 保证写入操作顺序与可控。我也提到过简单场景下的多消费者数据访问。更多的消费者的场景会变得更加复杂，我们 实现了一些聪明的机制允许多个消费者在访问 Ring Buffer 的时候互相等待（依赖）。像很多应用里，有一连串的工作需要在实际执行业务逻辑之前完成 (happen before) —— 例如，在做任何操作之前，我们都必须先保证消息写入磁盘。
Disruptor 论文 和性能测试里包含了你可能想到的一些基本结构。我准备讲一下其中最有趣的那个，这多半是因为我需要练习如何使用画图板。 阅读全文
原文地址：jenkov 作者： Jakob Jenkov 译者：长源 校对：方腾飞
线程池（Thread Pool）对于限制应用程序中同一时刻运行的线程数很有用。因为每启动一个新线程都会有相应的性能开销，每个线程都需要给栈分配一些内存等等。
我们可以把并发执行的任务传递给一个线程池，来替代为每个并发执行的任务都启动一个新的线程。只要池里有空闲的线程，任务就会分配给一个线程执行。在线程池的内部，任务被插入一个阻塞队列（Blocking Queue ），线程池里的线程会去取这个队列里的任务。当一个新任务插入队列时，一个空闲线程就会成功的从队列中取出任务并且执行它。
原文地址：http://ifeve.com/dissecting-the-disruptor-writing-to-the-ring-buffer/
作者：Trisha 译者：廖涵 校对：方腾飞
这是 Disruptor 全方位解析（end-to-end view）中缺少的一章。当心，本文非常长。但是为了让你能联系上下文阅读，我还是决定把它们写进一篇博客里。
本文的 重点 是：不要让 Ring 重叠；如何通知消费者；生产者一端的批处理；以及多个生产者如何协同工作。 阅读全文
(13 votes, average: 4.54 out of 5)
Loading...
(6 votes, average: 3.33 out of 5)