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 中有哪些等待策略 的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！