Disruptor-06 中有哪些等待策略

Disruptor-06 中有哪些等待策略 ，相信很多没有经验的人对此束手无策，为此本文总结了问题出现的原因和解决方法，通过这篇文章希望你能解决这个问题。

//.....
        // Construct the Disruptor with a SingleProducerSequencer
        Disruptor<LongEvent> disruptor = new Disruptor(
            factory, bufferSize, DaemonThreadFactory.INSTANCE, ProducerType.SINGLE, new BlockingWaitStrategy());
        //.....

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.

BlockingWaitStrategy使用一个典型的锁和条件变量来处理线程唤醒。BlockingWaitStrategy是可用的等待策略中最慢的策略，但在CPU使用方面是最保守的策略，可以在各种部署环境中提供最一致的行为表现。据了解，已部署的系统仍带来额外的性能提升。

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使用方面保持保守，但是在循环的中间使用一个LockSupport.parkNanos(1)调用。在一个典型的Linux系统将为约60µs暂停的线程。但是，它的好处是，产生线程不需要采取任何其他操作来增加适当的计数器，也不需要发送条件变量的代价。但是，在生产者线程和消费者线程之间移动事件的平均延迟会更高。它在不需要低延迟，但希望对生成线程有低影响的情况下工作得最好。一个常见的用例是异步日志记录。

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是可以在低延迟系统中使用的两种等待策略之一，在低延迟系统中可以选择消耗CPU周期，以改善延迟。YieldingWaitStrategy将忙于旋转，等待序列增加到适当的值。在循环体内部调用Thread.yield()，以允许其他排队的线程运行。当需要非常高的性能和事件处理，程序线程数小于逻辑内核总数时，这是推荐的等待策略，例如启用了超线程。

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是执行效率最高的等待策略，但是对部署环境的限制也最高。只有当事件处理程序线程的数量小于机器上物理内核的数量时，才应该使用此等待策略。例如，应该禁用超线程。

看完上述内容，你们掌握Disruptor-06 中有哪些等待策略 的方法了吗？如果还想学到更多技能或想了解更多相关内容，欢迎关注亿速云行业资讯频道，感谢各位的阅读！