Disruptor-06 中有哪些等待策略

Disruptor-06 中有哪些等待策略 ，相信很多沒有經(jīng)驗的人對此束手無策，為此本文總結(jié)了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個問題。

//.....
        // 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使用方面是最保守的策略，可以在各種部署環(huán)境中提供最一致的行為表現(xiàn)。據(jù)了解，已部署的系統(tǒng)仍帶來額外的性能提升。

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通過使用一個簡單的繁忙等待循環(huán)，試圖在CPU使用方面保持保守，但是在循環(huán)的中間使用一個LockSupport.parkNanos(1)調(diào)用。在一個典型的Linux系統(tǒng)將為約60μs暫停的線程。但是，它的好處是，產(chǎn)生線程不需要采取任何其他操作來增加適當(dāng)?shù)挠嫈?shù)器，也不需要發(fā)送條件變量的代價。但是，在生產(chǎn)者線程和消費者線程之間移動事件的平均延遲會更高。它在不需要低延遲，但希望對生成線程有低影響的情況下工作得最好。一個常見的用例是異步日志記錄。

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是可以在低延遲系統(tǒng)中使用的兩種等待策略之一，在低延遲系統(tǒng)中可以選擇消耗CPU周期，以改善延遲。YieldingWaitStrategy將忙于旋轉(zhuǎn)，等待序列增加到適當(dāng)?shù)闹?。在循環(huán)體內(nèi)部調(diào)用Thread.yield()，以允許其他排隊的線程運行。當(dāng)需要非常高的性能和事件處理，程序線程數(shù)小于邏輯內(nèi)核總數(shù)時，這是推薦的等待策略，例如啟用了超線程。

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是執(zhí)行效率最高的等待策略，但是對部署環(huán)境的限制也最高。只有當(dāng)事件處理程序線程的數(shù)量小于機器上物理內(nèi)核的數(shù)量時，才應(yīng)該使用此等待策略。例如，應(yīng)該禁用超線程。

看完上述內(nèi)容，你們掌握Disruptor-06 中有哪些等待策略 的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注億速云行業(yè)資訊頻道，感謝各位的閱讀！