鍍金池/ 教程/ Java/ Disruptor Wizard已死,Disruptor Wizard永存!
Ringbuffer的特別之處
寫(xiě)入 Ringbuffer
鎖的缺點(diǎn)
神奇的緩存行填充
如何從Ringbuffer讀取
Disruptor Wizard已死,Disruptor Wizard永存!
線程間共享數(shù)據(jù)無(wú)需競(jìng)爭(zhēng)
LMAX Disruptor——一個(gè)高性能、低延遲且簡(jiǎn)單的框架
通過(guò) Axon 和 Disruptor處理 1M tps
揭秘內(nèi)存屏障
Disruptor (無(wú)鎖并發(fā)框架)-發(fā)布
LMAX架構(gòu)
偽共享(False Sharing)
解析 Disruptor 的依賴關(guān)系
Disruptor 2.0 更新摘要

Disruptor Wizard已死,Disruptor Wizard永存!

原文地址:The Disruptor Wizard is Dead, Long Live the Disruptor Wizard!

譯者:楊帆 校對(duì):丁一

Disruptor Wizard(上一篇中提到的 DSL 組件)目前已經(jīng)正式并入 Disrupto r的代碼樹(shù)當(dāng)中。既然 .net 移植版包含了 Wizard 風(fēng)格的語(yǔ)法很久了,并且看起來(lái)還挺受歡迎,所以為什么還要讓人們非得搞兩個(gè) jar 而不是一個(gè)?

我跟隨 Disruptor 在術(shù)語(yǔ)命名上的變動(dòng)做出了相應(yīng)的更新。以前的 Customer(消費(fèi)者),現(xiàn)在叫 EventProcessor(事件處理器)和 EventHandler(事件句柄)。這樣的命名更好的說(shuō)明了實(shí)際上的情況:消費(fèi)者事實(shí)上可以向事件添加附加值。另外,ProducerBarrier(生產(chǎn)者屏障)被合并到 Ring Buffer 一起,并且 Ring Buffer Entry(條目)被改名為 Event (事件)。新的命名更貼切了,因?yàn)閷?shí)際上圍繞 Disruptor 的編程模型大部分時(shí)候都是基于事件的。

除了以下兩點(diǎn),Wizard API 與以往并沒(méi)有太大的不同:

  • consumeWith 方法改名為 handleEventsWith
  • getProducerBarrier 方法被替換成了一個(gè)返回值為 ring buffe r的 start 方法。這就不會(huì)混淆地認(rèn)為 getProducerBarrier 方法也被用作觸發(fā)事件處理器線程的啟動(dòng)。

現(xiàn)在的方法命名清楚地表示了該方法的其它作用。

原創(chuàng)文章,轉(zhuǎn)載請(qǐng)注明: 轉(zhuǎn)載自并發(fā)編程網(wǎng) – ifeve.com

本文鏈接地址: Disruptor Wizard已死,Disruptor Wizard永存!