生產(chǎn)替代物料

最近在InfoQ上，Aliasei Papou發(fā)表了一篇關(guān)于他的一些實(shí)驗(yàn)的文章 ，該實(shí)驗(yàn)在線程之間進(jìn)行了高性能的消息交換。 本文中有許多示例，但我將重點(diǎn)介紹多生產(chǎn)者案例。 文章顯示的一種優(yōu)化方法是，如果您知道初始化時(shí)擁有的生產(chǎn)者數(shù)量，則可以構(gòu)建一個(gè)可以大大減少競爭的結(jié)構(gòu)。 現(xiàn)有的MultiProducerSequencer不具有此約束，這對(duì)于大量用例而言是必不可少的。 但是，我想看看如果將這種方法應(yīng)用于Disruptor，我們可以實(shí)現(xiàn)什么。

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

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個(gè)數(shù)組傳遞到其構(gòu)造函數(shù)中：

• 數(shù)據(jù)提供者[]； 環(huán)形緩沖區(qū)數(shù)組，用于從中讀取數(shù)據(jù)。
• SequenceBarrier []; 每個(gè)環(huán)形緩沖區(qū)提供的屏障。

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

為了測試這一點(diǎn)，我創(chuàng)建了ThreeToThreeSequencedThroughputTest ，它啟動(dòng)了三個(gè)生產(chǎn)者和一個(gè)消費(fèi)者。 InfoQ文章中提供的代碼的方面之一是，每列火車的容量為三長，而“運(yùn)”則以一長的運(yùn)動(dòng)量度。 為了使測試更具可比性，我在環(huán)形緩沖區(qū)中使用了一個(gè)由三個(gè)long組成的數(shù)組作為條目，并將線程之間移動(dòng)的事件總數(shù)乘以3，以計(jì)算出總的“ ops”。

測試結(jié)果（英特爾?酷睿?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

顯然，這種方法有一些優(yōu)點(diǎn)。 我正在考慮將此添加到主要Disruptor發(fā)行版中。 但是，我仍然需要先解決幾個(gè)設(shè)計(jì)問題。

傳遞給處理程序的序列值是來自源環(huán)形緩沖區(qū)的值，并且隨著事件的流逝可能會(huì)上升和下降，我不確定這是否會(huì)對(duì)用戶造成問題。 感覺這是一件相當(dāng)次要的事情，所以希望我不必?fù)?dān)心。 事件處理器目前僅支持yield。 我需要弄清楚如何正確地包含等待策略，因?yàn)樽枞却呗院拖M(fèi)者喚醒會(huì)有些麻煩。

這是我們?cè)卩]件列表上提到的一個(gè)想法，最初我并不特別感興趣，但是鑒于這種方法有明顯的好處，我想我會(huì)更認(rèn)真地對(duì)待這個(gè)想法。

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

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

生產(chǎn)替代物料

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。