最近在InfoQ上，Aliasei Papou發表了一篇關于他的一些實驗的文章 ，該實驗在線程之間進行了高性能的消息交換。 本文中有許多示例，但我將重點介紹多生產者案例。 文章顯示的一種優化方法是，如果您知道初始化時擁有的生產者數量，則可以構建一個可以大大減少競爭的結構。 現有的MultiProducerSequencer不具有此約束，這對于大量用例而言是必不可少的。 但是，我想看看如果將這種方法應用于Disruptor，我們可以實現什么。

我要使用的設計是，不是使用MultiProducerSequencer使用單個Disruptor，而是使用每個生產者使用SingleProducerSequencer的每個Disruptor。 為了使所有事件通道進入單個EventHandler，我將需要實現一個自定義EventProcessor，它具有輪詢多個SequenceBarrier / DataProvider的能力。 在性能測試的com.lmax.disruptor.support程序包中可以看到此自定義MultiBufferBatchEventProcesor 。 該類的關鍵組件是主循環，可以在這里看到：

while (true) {try{for (int i = 0; i < barrierLength; i++){long available = barriers[i].waitFor(-1);Sequence sequence = sequences[i];long previous = sequence.get();for (long l = previous + 1; l <= available; l++){handler.onEvent(providers[i].get(l), l, previous == available);}sequence.set(available);count += (available - previous);}Thread.yield();}// Lines omitted... }

這種方法的核心是事件處理器將2個數組傳遞到其構造函數中：

• 數據提供者[]; 環形緩沖區數組，用于從中讀取數據。
• SequenceBarrier []; 每個環形緩沖區提供的屏障。

由此事件處理器將構造一個Sequence數組，該數組將用于跟蹤來自每個環形緩沖區的已處理事件。 事件循環將遍歷序列屏障，以確定是否有任何環形緩沖區具有可讀取的數據。 任何可用的數據都將傳遞到用戶提供的事件處理程序上。

為了測試這一點，我創建了ThreeToThreeSequencedThroughputTest ，該測試啟動了三個生產者和一個消費者。 InfoQ文章中提供的代碼的方面之一是，每列火車的容量為三長，而“運”則以一長的運動量度。 為了使測試更具可比性，我在環形緩沖區中使用了一個由三個long組成的數組作為條目，并將線程之間移動的事件總數乘以3，以計算出總的“ ops”。

測試結果（英特爾?酷睿?i7-3770 CPU @ 3.40GHz）

干擾者：

Run 0, Disruptor=390,738,060 ops/sec Run 1, Disruptor=387,931,034 ops/sec Run 2, Disruptor=397,058,823 ops/sec Run 3, Disruptor=394,160,583 ops/sec Run 4, Disruptor=396,767,083 ops/sec Run 5, Disruptor=394,736,842 ops/sec Run 6, Disruptor=396,767,083 ops/sec

鐵路/火車：

ops/sec = 243,141,801 ops/sec = 302,695,445 ops/sec = 283,096,862 ops/sec = 273,670,298 ops/sec = 268,340,387 ops/sec = 264,802,500 ops/sec = 262,258,028

顯然，這種方法有一些優點。 我正在考慮將此添加到主要Disruptor發行版中。 但是，我仍然需要先解決幾個設計問題。

傳遞給處理程序的序列值是來自源環形緩沖區的值，并且可能隨著事件的流逝而上升和下降，我不確定這是否會對用戶造成問題。 感覺這是一件相當次要的事情，所以希望我不必擔心。 事件處理器目前僅支持yield。 我需要弄清楚如何正確地包含等待策略，因為阻塞等待策略和消費者喚醒會帶來一些麻煩。

這個想法是我們在郵件列表上提到的，我最初并不特別感興趣，但是鑒于這種方法有明顯的好處，我想我會更認真地對待這個想法。

參考：來自Bad Concurrency博客的JCG合作伙伴 Michael Barker 的替代性多生產者方法 。

翻譯自: https://www.javacodegeeks.com/2013/12/an-alternative-multi-producer-approach.html

總結

以上是生活随笔為你收集整理的一种替代的多生产者方法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。