Disruptor是一个开源的Java框架，它被设计用于在生产者—消费者（producer-consumer problem，简称PCP）问题上获得尽量高的吞吐量（TPS）和尽量低的延迟。Disruptor是LMAX在线交易平台的关键组成部分，LMAX平台使用该框架对订单处理速度能达到600万TPS，除金融领域之外，其他一般的应用中都可以用到Disruptor，它可以带来显著的性能提升。其实Disruptor与其说是一个框架，不如说是一种设计思路，这个设计思路对于存在“并发、缓冲区、生产者—消费者模型、事务处理”这些元素的程序来说，Disruptor提出了一种大幅提升性能（TPS）的方案。
现在有很多人写过关于Disruptor文章，但是我还是想写这篇浅析，毕竟不同人的理解是不同的，希望没接触过它的人能通过本文对Disruptor有个初步的了解，本文后面给出了一些相关链接供参考。
什么是Disruptor？为什么速度更快？
简单的说，Disruptor是一个高性能的Buffer，并提供了使用这个Buffer的框架。为什么说是它性能更好呢？这得从PCP和传统解决办法的缺点开始说起。
我们知道，PCP又称Bounded-Buffer问题，其核心就是保证对一个Buffer的存取操作在多线程环境下不会出错。使用Java中的ArrayBlockingQueue和LinkedBlockingQueue类能轻松的完成PCP模型，这对于一般程序已经没问题了，但是对于并发度高、TPS要求较大的系统则不然。
BlockingQueue使用的是package java.util.concurrent.locks中实现的锁，当多个线程（例如生产者）同时写入Queue时，锁的争抢会导致只有一个生产者可以执行，其他线程都中断了，也就是线程的状态从RUNNING切换到BLOCKED，直到某个生产者线程使用完Buffer后释放锁，其他线程状态才从BLOCKED切换到RUNNABLE，然后时间片到其他线程后再进行锁的争抢。上述过程中，一般来说生产者存放一个数据到Buffer中所需时间是非常短的，操作系统切换线程上下文的速度也是非常快的，但是当线程数量增多后，OS切换线程所带来的开销逐渐增多，锁的反复申请和释放成为性能瓶颈。BlockingQueue除了使用锁带来的性能损失外，还可能因为线程争抢的顺序问题造成性能再次损失：实际使用中发现线程的调度顺序并不理想，可能出现短时间内OS频繁调度出生产者或消费者的情况，这样造成缓冲区可能短时间内被填满或被清空的极端情况。（理想情况应该是缓冲区长度适中，生产和消费速度基本一致）
对于上面的问题Disruptor的解决方案是：不用锁。
Ring Buffer示意图：
Disruptor使用一个Ring Buffer存放生产者的“产品”，环形缓冲区实际上还是一段连续内存，之所以称作环形是因为它对数据存放位置的处理，生产者和消费者各有一个指针（数组下标），消费者的指针指向下一个要读取的Slot，生产者指针指向下一个要放入的Slot，消费或生产后，各自的指针值p = (p +1) % n，n是缓冲区长度，这样指针在缓冲区上反复游走，故可以将缓冲区看成环状。（如右图）（Ring Buffer并非Disruptor原创，Linux内核中就有环形缓冲区的实现。）使用Ring Buffer时：
- 当生产者和消费者都只有一个时，由于两个线程分别操作不同的指针，所以不需要锁。
- 当有多个消费者时，（按Disruptor的设计）每个消费者各自控制自己的指针，依次读取每个Slot（也就是每个消费者都会读取到所有的产品），这时只需要保证生产者指针不会超过最慢的消费者（超过最后一个消费者“一圈”）即可，也不需要锁。
- 当有多个生产者时，多个线程共用一个写指针，此处需要考虑多线程问题，例如两个生产者线程同时写数据，当前写指针=0，运行后其中一个线程应获得缓冲区0号Slot，另一个应该获得1号，写指针=2。对于这种情况，Disruptor使用CAS来保证多线程安全。
CAS(Compare and Swap/Set)是现在CPU普遍支持的一种指令（例如cmpxchg系类指令），CAS操作包含3个操作数：CAS(A,B,C)，其功能是：取地址A的值与B比较，如果相同，则将C赋值到地址A。CAS特点是它是由硬件实现的极轻量级指令，同时CPU也保证此操作的原子性。在考虑线程间同步问题时，可以使用Unsafe类的boolean compareAndSwapInt(java.lang.Object arg0, long arg1, int arg2, int arg3);系列方法，对于一个int变量（例如，Ring Buffer的写指针），使用CAS可以避免多线程访问带来的混乱，当compareAndSwap方法true时表明CAS操作成功赋值，返回false则表明地址A处的值并不等于B，此时重新试一遍即可，使用CAS移动写指针的逻辑如下：
//写指针向后移动n
public long next(int n)
{
//......
long current,next;
do
{
//此处先将写指针的当前值备份一下
current = pointer.get();
//预计写指针将要移动到的位置
next = current + n;
//......省略：确保从current到current+n的Slot已经被消费者读完......
//*原子操作*如果当前写指针和刚才一样（说明9-12行的计算有效），那么移动写指针
if ( pointer.comapreAndSet(current,next) )
break;
}while ( true )//如果CAS失败或者还不能移动写指针，则不断尝试
return next;
} OK，我们现在有了一个使用CAS的Ring Buffer，这比用锁快上不少，但CAS的效率并没有想象的那么快，根据链接[2]pdf中评测：和单一线程无锁执行某简单任务相比，使用锁的时间比无锁高出2个数量级，CAS也高出了一个数量级。那么Disruptor还有什么提高性能的地方呢？
Disruptor优化方法
下面列举一下除了无锁编程外的其他性能优化点。
缓存行填充（Cache Line Padding）
CPU缓存常以64bytes作为一个缓存行大小，缓存由若干个缓存行组成，缓存写回主存或主存写入缓存均是以行为单位，此外每个CPU核心都有自己的缓存（但是若某个核心对某缓存行做出修改，其他拥有同样缓存的核心需要进行同步），生产者和消费者的指针用long型表示，假设现在只有一个生产者和一个消费者，那么双方的指针间没有什么直接联系，只要不“挨着”，应该可以各改各的指针。OK前面说有点乱，但都是前提，下面问题来了：如果生产者和消费者的指针（加起来共16bytes）出现在同一个缓存行中会怎么样？例如CPU核心A运行的消费者修改了一下自己的指针值(P1)，那么其他核心中所有缓存了P1的缓存行都将失效，并从主存重新调配。这样做的缺点显而易见，但是CPU和编译器并未聪明到避免这个问题，所以需要缓存行填充。虽然问题产生的原因很绕，但是解决方案却非常简单：对于一个long型的缓冲区指针，用一个长度为8的long型数组代替。如此一来，一个缓存行被这个数组填充满，线程对各自指针的修改不会干扰到他人。
避免GC
写Java程序的时候，很多人习惯随手new各种对象，虽然Java的GC会负责回收，但是系统在高压力情况下频繁的new必定导致更频繁的GC，Disruptor避免这个问题的策略是：提前分配。在创建RingBuffer实例时，参数中要求给出缓冲区元素类型的Factory，创建实例时，Ring Buffer会首先将整个缓冲区填满为Factory所产生的实例，后面生产者生产时，不再用传统做法（顺手new一个实例出来然后add到buffer中），而是获得之前已经new好的实例，然后设置其中的值。举个形象的例子就是，若缓冲区是个放很多纸片的地方，纸片上记录着信息，以前的做法是：每次加入缓冲区时，都从系统那现准备一张纸片，然后再写好纸片放进缓冲区，消费完就随手扔掉。现在的做法是：实现准备好所有的纸片，想放入时只需要擦掉原来的信息写上新的即可。
成批操作（Batch）
Ring Buffer的核心操作是生产和消费，如果能减少这两个操作的次数，性能必然相应地提高。Disruptor中使用成批操作来减少生产和消费的次数，下面具体说一下Disruptor的生产和消费过程中如何体现Batch的。向RingBuffer生产东西的时候，需要经过2个阶段：阶段一为申请空间，申请后生产者获得了一个指针范围[low,high]，然后再对缓冲区中[low,high]这段的所有对象进行setValue（见优化点②），阶段2为发布（像这样ringBuffer.publish(low,high);）。阶段1结束后，其他生产者再申请的话，会得到另一段缓冲区。阶段2结束后，之前申请的这一段数据就可以被消费者读到。Disruptor推荐成批生产、成批发布，减少生产时的同步带来的性能损失。从RingBuffer消费东西的时候也需要两个阶段，阶段一为等待生产者的（写）指针值超过指定值（N，即N之前的数据已经消费过了），阶段一执行完后，消费者会得到一个指针值（R），表示Ring Buffer中下标R之前的值是可以读的。阶段2就是具体读取（略）。阶段一返回值R很有可能大于N，此时消费者应该进行成批读取操作，将[R,N]范围内的数据全部处理。
604
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
