我们接着介绍Disruptor高性能实现之道–等待策略。
等待策略waitStrategy是一种决定一个消费者如何等待生产者将event对象放入Disruptor的方式/策略。
等待策略waitStrategy是一个接口，它的所有实现都是针对消费者生效的。
Disruptor中，等待策略waitStrategy有四个实现，分别是：
BlockingWaitStrategy：使用锁和条件变量实现的阻塞策略。如果不是将吞吐量和低延迟放在首位，则可以使用该策略。一般来说，这个策略的表现是中规中矩比较稳定的，它不会使CPU的负载飙高。
虽然客观上说， BlockingWaitStrategy是最低效的策略，但其也是CPU使用率最低和最稳定的策略。
在BlockingWaitStrategy内部维护了一个重入锁ReentrantLock和Condition；
SleepingWaitStrategy：性能表现和com.lmax.disruptor.BlockingWaitStrategy差不多，对CPU的消耗也类似，但其对生产者线程的影响最小，适合用于异步日志类似的场景；
SleepingWaitStrategy是一种无锁的方式，它的CPU使用率也比较低。具体的实现原理为：循环等待并且在循环中间调用LockSupport.parkNanos(1)来睡眠，（在Linux系统上面睡眠时间60μs）.
SleepingWaitStrategy优点在于生产线程只需要计数，而不执行任何指令。并且没有条件变量的消耗。但是，事件对象从生产者到消费者传递的延迟变大了。SleepingWaitStrategy最好用在不需要低延迟，而且事件发布对于生产者的影响比较小的情况下。比如异步日志功能。
YieldingWaitStrategy：性能最好，适合用于低延迟的系统，在要求极高性能且事件处理线程数小于CPU逻辑核心数的场景中推荐使用此策略，例如CPU开启超线程的特性；
虽然YieldingWaitStrategy性能最好，但是它的实现机制是让出cpu使用权，保证cpu不会空闲，从而使得cpu始终处于工作态，因此该策略会使用100%的CPU，因此建议慎用。
BusySpinWaitStrategy发挥高性能的前提是事件处理线程比物理内核数目还要小的场景。例如：在禁用超线程技术的时候。
?