disruptor调优方法

翻译自disruptor在github上的文档，https://github.com/LMAX-Exchange/disruptor/wiki/Getting-Started

Basic Tuning Options 基本的调优方法

Using the above approach will work functionally in the widest set of deployment scenarios. However, if you able to make certain assumptions about the hardware and software environment that the Disruptor will run in then you can take advantage of a number of tuning options to improve performance. There are 2 main options for tuning, single vs. multiple producers and alternative wait strategies. ------------------------------------------------------------------------------------------------- 使用上面方法在大多数的部署场景里都可以很好的工作。 但是，如果你能搞清楚你将在什么样的硬件和软件环境中运行disruptor的话，有一些个调优方法能够提高性能。 主要有2种方法进行调优：单生产者vs多生产者，选择合适的等待策略。

Single vs. Multiple Producers  单生产者还是多生产者？

One of the best ways to improve performance in concurrect systems is to ahere to the Single Writer Princple, this applies to the Disruptor. If you are in the situation where there will only ever be a single thread producing events into the Disruptor, then you can take advantage of this to gain additional performance. 改进并发系统性能的最佳办法之一就是遵守“单写入者”定律，Disruptor就是这样干的。 如果你只需要用一个单生产者线程生成事件投入Disruptor的话，这样的应用场景会获得额外的性能表现。

public class LongEventMain {    

　　public static void main(String[] args) throws Exception     {        

　　//.....        

　　// Construct the Disruptor with a SingleProducerSequencer        

　　Disruptor<LongEvent> disruptor = new Disruptor(factory,       

　　　　　　　　　　　　　　　　　　　　　　　　　　　　bufferSize,     

　　　　　　　　　　　　　　　　　　　　　　　　　　　　ProducerType.SINGLE, // Single producer                                                       

　　　　　　　　　　　　　　　　　　　　　　　　　　　　new BlockingWaitStrategy(),   

　　　　　　　　　　　　　　　　　　　                    　　executor);

        //.....     }

}

To give an indication of how much of a performance advantage can be achieved through this technique we can change the producer type in the OneToOne performance test. Tests run on i7 Sandy Bridge MacBook Air. 为了证明这样的技术到底能带来多少性能上的提升， 我们可以通过调整producerType来一场1对1的性能测试。（译者注：ProducersType.Single vs. ProducersType.Multiple ） 测试环境：i7 Sandy Bridge MacBook Air

Multiple Producer

Run 0, Disruptor=26,553,372 ops/sec

Run 1, Disruptor=28,727,377 ops/sec

Run 2, Disruptor=29,806,259 ops/sec

Run 3, Disruptor=29,717,682 ops/sec

Run 4, Disruptor=28,818,443 ops/sec

Run 5, Disruptor=29,103,608 ops/sec

Run 6, Disruptor=29,239,766 ops/sec

Single Producer

Run 0, Disruptor=89,365,504 ops/sec

Run 1, Disruptor=77,579,519 ops/sec

Run 2, Disruptor=78,678,206 ops/sec

Run 3, Disruptor=80,840,743 ops/sec

Run 4, Disruptor=81,037,277 ops/sec

Run 5, Disruptor=81,168,831 ops/sec

Run 6, Disruptor=81,699,346 ops/sec

Alternative Wait Strategies 可选择的等待策略

BlockingWaitStrategy 阻塞等待策略

The default wait strategy used by the Disruptor is the BlockingWaitStrategy. Internally the BlockingWaitStrategy uses a typical lock and condition variable to handle thread wake-up. The BlockingWaitStrategy is the slowest of the available wait strategies, but is the most conservative with the respect to CPU usage and will give the most consistent behaviour across the widest variety of deployment options. However, again knowledge of the deployed system can allow for additional performance. -------------------------------------------------------------------------------------------------------- disruptor的默认消费者等待策略是BlockingWaitStrategy。 BlockingWaitStrategy内部使用的是典型的锁和条件变量机制，来处理线程的唤醒。 这种策略是所有disruptor等待策略中最慢的一种，但是是最保守使用消耗cpu的一种用法，并且在不同的部署环境下最能保持性能一致。 但是，随着我们对部署系统的了解可以优化出额外的性能。（译者注：BlockingWaitStrategy是适用面最广的默认策略， 但是随着对具体系统部署环境的具体分析，我们可以采用其他策略替换它，来取得更好的优化性能）

SleepingWaitStrategy  休眠等待策略

Like the BlockingWaitStrategy the SleepingWaitStrategy it attempts to be conservative with CPU usage, by using a simple busy wait loop, but uses a call to  LockSupport.parkNanos(1)  in the middle of the loop. On a typical Linux system this will pause the thread for around 60μs. However it has the benefit that the producing thread does not need to take any action other increment the appropriate counter and does not require the cost of signalling a condition variable. However, the mean latency of moving the event between the producer and consumer threads will be higher. It works best in situations where low latency is not required, but a low impact on the producing thread is desired. A common use case is for asynchronous logging. --------------------------------------------------------------------------------------------------------- 像BlockingWaitStrategy一样，SleepingWaitStrategy也是属于一种保守使用cpu的策略。 它使用一个简单的loop繁忙等待循环，但是在循环体中间它调用了LockSupport.parkNanos(1)。 通常在linux系统这样会使得线程停顿大约60微秒。但是这样做的好处是，生产者线程不需要额外的动作去累加计数器，也不需要产生条件变量信号量开销。 但是这样带来的负面影响是，在生产者线程与消费者线程之间传递event的延迟变高了。所以SleepingWaitStrategy适合在不需要低延迟， 但需要很低的生产者线程影响的情形。一个典型的案例就是异步日志记录功能。

YieldingWaitStrategy  服从等待策略

The YieldingWaitStrategy is one of 2 Wait Strategies that can be use in low latency systems, where there is the option to burn CPU cycles with the goal of improving latency. The YieldingWaitStrategy will busy spin waiting for the sequence to increment to the appropriate value. Inside the body of the loop  Thread.yield()  will be called allowing other queued threads to run. This is the recommended wait strategy when need very high performance and the number of Event Handler threads is less than the total number of logical cores, e.g. you have hyper-threading enabled. ---------------------------------------------------------------------------------------------------------- YieldingWaitStrategy是2种可以用于低延迟系统的等待策略之一，充分使用压榨cpu来达到降低延迟的目标。 YieldingWaitStrategy不断的循环等待sequence去递增到合适的值。 在循环体内，调用Thread.yield()来允许其他的排队线程执行。 这是一种在需要极高性能并且event handler线程数少于cpu逻辑内核数的时候推荐使用的策略。 例如，你开启了超线程。（译者注：超线程是intel研发的一种cpu技术，可以使得一个核心提供两个逻辑线程，比如4核心超线程后有8个线程）

BusySpinWaitStrategy  繁忙旋转等待策略

The BusySpinWaitStrategy is the highest performing Wait Strategy, but puts the highest constraints on the deployment environment. This wait strategy should only be used if the number of Event Handler threads is smaller than the number of physical cores on the box.  E.g. hyper-threading should be disabled. BusySpinWaitStrategy是性能最高的等待策略，但是受部署环境的制约依赖也越强。 仅仅当event处理线程数少于物理核心数的时候才应该采用这种等待策略。 例如，超线程不可开启。