Disruptor 系列（一）快速入门
Disruptor：是一个开源的并发框架，能够在 无锁 的情况下实现网络的 Queue 并发操作，所以处理数据的能力比 Java 本身提供的并发类容器要大的多，在一个线程里每秒处理 6 百万订单。 可以把它当作一个轻量级的 MQ 和无锁的 BlockingQueue。
一、BlockingQueue
jdk 常用的队列有
| 队列 | 有界性 | 锁 | 数据结构 |
|---|---|---|---|
| ArrayBlockingQueue | bounded | 加锁 | arraylist |
| LinkedBlockingQueue | optionally-bounded | 加锁 | linkedlist |
| ConcurrentLinkedQueue | unbounded | 无锁 | linkedlist |
| LinkedTransferQueue | unbounded | 无锁 | linkedlist |
| PriorityBlockingQueue | unbounded | 加锁 | heap |
| DelayQueue | unbounded | 加锁 | heap |
考虑到内存回收，防止无界队列内存溢出，通常使用 ArrayBlockingQueue。常用于生产者-消费者模式：
二、Disruptor 特点
-
Disruptor 是一个 Java 的并发编程框架，大大的简化了并发程序开发的难度，在性能上也比 Java 本身提供的一些并发包要好。
-
Disruptor 是一个高性能异步处理框架，它实现了观察者模式，或者事件监听模式的实现。
-
Disruptor 是无锁的、CPU 友好，它不会清除缓存中的数据，只会覆盖，降低了垃圾回收机制启动的频率。
三、HelloWorld 代码
可以通过 Maven安装Disruptor。查看 Getting-Started 快速入门，更多API
<dependency>
<groupId>com.lmax</groupId>
<artifactId>disruptor</artifactId>
<version>3.3.7</version>
</dependency>
我们从一个简单的例子开始学习 Disruptor：生产者传递一个 long 类型的值给消费者，而消费者消费这个数据的方式仅仅是把它打印出来。首先声明一个 Event 来包含需要传递的数据：
public class LongEvent {
private long value;
public long getValue() {
return value;
}
public void setValue(long value) {
this.value = value;
}
}
由于需要让 Disruptor 为我们创建事件，我们同时还声明了一个 EventFactory 来实例化 Event 对象。
public class LongEventFactory implements EventFactory {
@Override
public Object newInstance() {
return new LongEvent();
}
}
我们还需要一个事件消费者，也就是一个事件处理器。这个事件处理器简单地把事件中存储的数据打印到终端：
public class LongEventHandler implements EventHandler<LongEvent> {
@Override
public void onEvent(LongEvent longEvent, long l, boolean b) throws Exception {
System.out.println(longEvent.getValue());
}
}
事件都会有一个生成事件的源，可以简单的理解为一个事件生产者。这个例子中假设事件是由于磁盘IO或者network读取数据的时候触发的，事件源使用一个ByteBuffer来模拟它接受到的数据，也就是说，事件源会在IO读取到一部分数据的时候触发事件（触发事件不是自动的，程序员需要在读取到数据的时候自己触发事件并发布）：
public class LongEventProducer {
private final RingBuffer<LongEvent> ringBuffer;
public LongEventProducer(RingBuffer<LongEvent> ringBuffer){
this.ringBuffer = ringBuffer;
}
/**
* onData用来发布事件，每调用一次就发布一次事件
* @param ByteBuffer 它的参数会用过事件传递给消费者
*/
public void onData(ByteBuffer bb){
//1.可以把ringBuffer看做一个事件队列，那么next就是得到下面一个事件槽
long sequence = ringBuffer.next();
try {
//2.用上面的索引取出一个空的事件用于填充（获取该序号对应的事件对象）
LongEvent event = ringBuffer.get(sequence);
//3.获取要通过事件传递的业务数据
event.setValue(bb.getLong(0));
} finally {
//4.发布事件
//注意，最后的 ringBuffer.publish 方法必须包含在 finally 中以确保必须得到调用；
// 如果某个请求的 sequence 未被提交，将会堵塞后续的发布操作或者其它的 producer。
ringBuffer.publish(sequence);
}
}
}
很明显的是：当用一个简单队列来发布事件的时候会牵涉更多的细节，这是因为事件对象还需要预先创建。发布事件最少需要两步：获取下一个事件槽并发布事件（ 发布事件的时候要使用 try/finally 保证事件一定会被发布 ）。如果我们使用 RingBuffer.next() 获取一个事件槽，那么一定要发布对应的事件。如果不能发布事件，那么就会引起 Disruptor 状态的混乱。尤其是在多个事件生产者的情况下会导致事件消费者失速，从而不得不重启应用才能会恢复。
Disruptor 3.0 提供了 lambda 式的 API。这样可以把一些复杂的操作放在 Ring Buffer，所以在 Disruptor3.0 以后的版本最好使用 Event Publisher 或者 Event Translator 来发布事件。
public class LongEventProducerWithTranslator {
//一个translator可以看做一个事件初始化器，publicEvent方法会调用它
private static final EventTranslatorOneArg<LongEvent, ByteBuffer> TRANSLATOR =
new EventTranslatorOneArg<LongEvent, ByteBuffer>() {
public void translateTo(LongEvent event, long sequence, ByteBuffer buffer) {
event.setValue(buffer.getLong(0));
}
};
private final RingBuffer<LongEvent> ringBuffer;
public LongEventProducerWithTranslator(RingBuffer<LongEvent> ringBuffer) {
this.ringBuffer = ringBuffer;
}
public void onData(ByteBuffer buffer) {
ringBuffer.publishEvent(TRANSLATOR, buffer);
}
}
最后一步就是把所有的代码组合起来完成一个完整的事件处理系统。
public class LongEventMain {
public static void main(String[] args) throws Exception {
//1. 创建disruptor
Disruptor<LongEvent> disruptor = new Disruptor<LongEvent>( // (1)
new LongEventFactory(), // 创建工厂
1024 * 1024, // RingBuffer 大小，必须是2的N次方
Executors.defaultThreadFactory(), // 线程池
ProducerType.SINGLE, // 单个生产者，如果有多个生产者必须使用 ProducerType.MULTI
new YieldingWaitStrategy() // 生产者和消费者的平衡策略
);
//2. 连接消费事件方法
disruptor.handleEventsWith(new LongEventHandler());
//3. 启动
disruptor.start();
//4. 发布事件
RingBuffer<LongEvent> ringBuffer = disruptor.getRingBuffer();
//LongEventProducer producer = new LongEventProducer(ringBuffer);
LongEventProducerWithTranslator producer = new LongEventProducerWithTranslator(ringBuffer);
ByteBuffer byteBuffer = ByteBuffer.allocate(8);
for(long l = 0; l<100; l++){
byteBuffer.putLong(0, l);
producer.onData(byteBuffer);
//Thread.sleep(1000);
}
disruptor.shutdown();//关闭 disruptor，方法会堵塞，直至所有的事件都得到处理；
}
}
-
Disruptor 构造方法如下：
new Disruptor( EventFactory<T> eventFactory, // 事件工厂类 int ringBufferSize, // RingBuffer 大小 ThreadFactory threadFactory, // ThreadFactory ProducerType producerType, // 生产模式，ProducerType.SINGLE ProducerType.MULTI WaitStrategy waitStrategy) // 等待策略，3种 -
WaitStrategy 策略类型：
-
BlockingWaitStrategy 是最低效的策略，但其对CPU的消耗最小并且在各种不同部署环境中能提供更加一致的性能表现
-
SleepingWaitStrategy 的性能表现跟BlockingWaitStrategy差不多，对CPU的消耗也类似，但其对生产者线程的影响最小，适合用于异步日志类似的场景
-
YieldingWaitStrategy 的性能是最好的，适合用于低延迟的系统。在要求极高性能且事件处理线数小于CPU逻辑核心数的场景中，推荐使用此策略；例如，CPU开启超线程的特性
-
四、Disruptor 组件说明
从生产者-消费者的整体：
-
RingBuffer: 被看作 Disruptor 最主要的组件，然而从 3.0 开始 RingBuffer 仅仅负责存储和更新在 Disruptor 中流通的数据。对一些特殊的使用场景能够被用户(使用其他数据结构)完全替代。更多Ringbuffer
-
Sequence: Disruptor 使用 Sequence 来表示一个特殊组件处理的序号。和 Disruptor 一样，每个消费者(EventProcessor)都维持着一个 Sequence。大部分的并发代码依赖这些 Sequence 值的运转，因此 Sequence 支持多种当前为 AtomicLong 类的特性。 -
Producer：由用户实现，它调用 RingBuffer 来插入事件(Event)。在 Disruptor 中没有相应的实现代码，由用户实现。 -
Event：从生产者到消费者过程中所处理的数据单元。在 Disruptor 中没有相应的实现代码，由用户定义的。 -
EventHandler：由用户实现并且代表了 Disruptor 中的一个消费者的接口。
从 Disruptor 框架如何处理 Event 的细节：
-
Sequencer: 这是 Disruptor 真正的核心。实现了这个接口的两种生产者（单生产者和多生产者）均实现了所有的并发算法，为了在生产者和消费者之间进行准确快速的数据传递。通过复杂的算法去协调生存者和消费者之间的关系。 -
SequenceBarrier: Sequecer具体的实施者，由 Sequencer 生成。它包含了决定是否有供消费者来消费的 Event 的逻辑。（生产者发布事件快于消费，生产者等待。消费速度大于生产者发布事件速度，消费者监听） -
EventProcessor：主要事件循环，处理 Disruptor 中的 Event，并且拥有消费者的 Sequence。它有一个实现类是 BatchEventProcessor，包含了event loop有效的实现，并且将回调到一个 EventHandler 接口的实现对象。 -
WorkProcessor：确保每个 sequence 只被一个 processor 消费，在同一个 WorkPool 中的处理多个 WorkProcessor 不会消费同样的 sequence。 -
LifecycleAware：当 BatchEventProcessor 启动和停止时，实现这个接口用于接收通知。 -
WaitStrategy：当消费者等待在SequenceBarrier上时，有许多可选的等待策略。- BusySpinWaitStrategy ： 自旋等待，类似 Linux Kernel 使用的自旋锁。低延迟但同时对 CPU 资源的占用也多。
- BlockingWaitStrategy ： 使用锁和条件变量。CPU 资源的占用少，延迟大。
- SleepingWaitStrategy ： 在多次循环尝试不成功后，选择让出 CPU，等待下次调度，多次调度后仍不成功，尝试前睡眠一个纳秒级别的时间再尝试。这种策略平衡了延迟和 CPU 资源占用，但延迟不均匀。
- YieldingWaitStrategy ： 在多次循环尝试不成功后，选择让出 CPU，等待下次调。平衡了延迟和 CPU 资源占用，但延迟也比较均匀。
- PhasedBackoffWaitStrategy ： 上面多种策略的综合，CPU 资源的占用少，延迟大。
参考：
https://blog.csdn.net/bohu83/article/details/78273246
每天用心记录一点点。内容也许不重要，但习惯很重要！