quasar 異步回調(diào)

“ Arien看到了我們運(yùn)行的parallelStreams和ForkJoin基準(zhǔn)測(cè)試的結(jié)果后，在Twitter上與我們聯(lián)系。 這激起了他的興趣，因此他進(jìn)行了一些自己的測(cè)試，將Quasar纖維加入了混合物。 這是他的結(jié)果和結(jié)論。” –塔基皮（Takipi）Alex Zhitnitsky

Arien Kock是Java軟件工程師。 他喜歡單口喜劇，并且曾經(jīng)是街頭霸王的競(jìng)爭(zhēng)者。

異步ForkJoinPool，managedBlock和Quasar在IO方案中如何執(zhí)行？

我認(rèn)為Quarar有很大的潛力。 除了允許更多數(shù)量的并行操作之外，Quasar的光纖還允許OS線程不是一對(duì)一的映射，還允許程序員以同步方式（使用continuation ）編寫代碼。 這比普通的異步風(fēng)格的代碼往往會(huì)帶來(lái)回調(diào)的痕跡使解釋和推理代碼更加容易。 對(duì)于輕量級(jí)線程的性能優(yōu)勢(shì)，我考慮暫停綠色線程的性能的提高/纖維與停車操作系統(tǒng)線程非常成熟 。 在這篇Takipi博客文章的激發(fā)下 ，我對(duì)Quasar在IO場(chǎng)景中的性能和替代方法感到好奇。 所以我做了一個(gè)基準(zhǔn)。

新話題：Java的IO基準(zhǔn)：類星體與異步ForkJoinPool與managedBlock http://t.co/2eoi4th2ZO pic.twitter.com/IDDGYPYvfI

— Takipi（@takipid） 2015年3月9日

設(shè)置

我使用JMH來(lái)避免重新發(fā)明測(cè)試輪的不良版本。 我首先找到了Caliper，但隨后在Stackoverflow上的某個(gè)地方讀到JMH“更好”。 這是我第一次使用它，但這是一次非常積極的經(jīng)歷。 它帶有事件探查器和自動(dòng)參數(shù)排列以及許多其他用于編寫微基準(zhǔn)測(cè)試的出色功能。 我的基準(zhǔn)比較了IO的三種樣式。 直接使用AsynchronousFileChannel（帶有回調(diào)），使用常規(guī)的阻塞FileChannel，但使用ForkJoinPool的managedBlock工具，最后：Quasar（在AsynchronousFileChannel周圍使用包裝器對(duì)象，使您可以編寫同步樣式代碼）。 我使用IO操作之間的一些計(jì)算工作來(lái)運(yùn)行測(cè)試，以從Quasar獲得大量上下文切換。 您可以在我的Github存儲(chǔ)庫(kù)中找到基準(zhǔn)代碼。 該基準(zhǔn)測(cè)試在Windows 8筆記本電腦上以安全模式（我知道避免干擾的最佳方式）在SSD驅(qū)動(dòng)器上運(yùn)行。

結(jié)果

通過(guò)5次熱身迭代和15個(gè)真實(shí)樣本，我相信這是非常準(zhǔn)確的。

差異遠(yuǎn)在誤差范圍之內(nèi)，我相信可以肯定地說(shuō)它們是相等的。 運(yùn)行堆棧分析器僅顯示托管阻塞和非阻塞（Quasar和Async FJP）類型之間的差異，這會(huì)產(chǎn)生非常不同的調(diào)用堆棧。 我創(chuàng)建了一個(gè)使用Socket進(jìn)行相同操作的基準(zhǔn)，但是我很確定實(shí)現(xiàn)中存在錯(cuò)誤。 如果有人想看一下代碼，請(qǐng)放心。

我預(yù)計(jì)托管塊會(huì)變慢，因?yàn)楫?dāng)無(wú)法保證FJP上的并行運(yùn)算能力時(shí)，它將分配額外的線程（使用計(jì)算任務(wù)確實(shí)如此）。 在運(yùn)行該基準(zhǔn)測(cè)試時(shí)，我什至無(wú)法正常啟動(dòng)VisualVM。 大量的線程使其加載極其緩慢。 盡管頻繁分配線程，但沒(méi)有區(qū)別。 類星體也是如此。 暫掛光纖的開(kāi)銷（保留執(zhí)行進(jìn)程的當(dāng)前狀態(tài)以釋放CPU內(nèi)核的操作）不會(huì)引起任何明顯的延遲。 在“引人注目的”是關(guān)鍵的地方……

結(jié)論

面對(duì)IO，這三種實(shí)現(xiàn)的速度差異不明顯。 如果我實(shí)現(xiàn)了一個(gè)滅火器軟管（CPU是瓶頸），那也沒(méi)關(guān)系，因?yàn)樵谒腥N實(shí)現(xiàn)中，常規(guī)（非IO）代碼都將以相同的速度和相同的并行度執(zhí)行。 那是因?yàn)镼uasar不會(huì)進(jìn)行任何上下文切換，除非光纖實(shí)際阻塞了。 如果光纖花費(fèi)太長(zhǎng)時(shí)間執(zhí)行而沒(méi)有光纖阻塞，類星體甚至?xí)l(fā)出警告。 似乎三種處理IO的性能均相同，這意味著對(duì)于這種類型的應(yīng)用程序，在這三種類型之間進(jìn)行選擇將是一個(gè)問(wèn)題。 但是，我認(rèn)為這只是部分正確。 在回調(diào)樣式和阻止樣式之間，如果我要做的是同時(shí)處理8個(gè)文件，則可以清楚地選擇阻止樣式。 容易掌握。 接下來(lái)，在托管塊（創(chuàng)建更多線程）和光纖塊之間進(jìn)行選擇，托管塊的工作量最少。 案件尚未完全結(jié)案，但是……

潛伏

在客戶端連接可以長(zhǎng)時(shí)間保持打開(kāi)的Web服務(wù)器中（例如，當(dāng)我們等待緩慢的客戶端和/或正在從數(shù)據(jù)庫(kù)中獲取數(shù)據(jù)時(shí)），在事務(wù)期間阻塞線程可能會(huì)導(dǎo)致線程饑餓。 這是Quasar真正發(fā)揮作用的地方，這要?dú)w功于將許多用戶空間線程復(fù)用到少量OS線程上。 然后有...

使用Quasar的（當(dāng)前）“困難”

截至目前，使用quasar意味著使用Java代理，這僅需要一點(diǎn)努力。 現(xiàn)有代碼也標(biāo)記為@Suspendable，以便Quasar可以檢測(cè)并阻止隨后運(yùn)行代碼的光纖。 在pom.xml中查找執(zhí)行發(fā)現(xiàn)/標(biāo)記的maven-antrun-plugin。 如果您使用的是具有回調(diào)樣式異步性的框架，那么您需要編寫的自定義代碼并不那么復(fù)雜，但是您仍然必須編寫它。 看看Pulsar的現(xiàn)成集成。

IO光纖：是或否

當(dāng)您要做的只是具有高吞吐量和低并行度的連續(xù)IO時(shí)，基準(zhǔn)測(cè)試不會(huì)顯示使用光纖的任何代價(jià)。 使用Quasar的額外工作（就額外的編碼和配置而言）是一系列一次性任務(wù)，（我認(rèn)為）這可以忽略不計(jì)。 Pulsar提供了一組很好的集成（盡管JDBC有點(diǎn)不足）。 使用這些和您自己的應(yīng)用程序，您可以創(chuàng)建一個(gè)IO繁重的應(yīng)用程序（例如Web應(yīng)用程序），該應(yīng)用程序具有一個(gè)用于接受連接的池和一個(gè)或多個(gè)用于處理后端調(diào)用的池。 您最終得到的是線程池，這些線程在后臺(tái)將任務(wù)相互傳遞，而您的邏輯仍然以同步的方式從上到下讀取，最后是return語(yǔ)句。

如果像大多數(shù)小型應(yīng)用程序一樣，您最多只能為數(shù)百名同時(shí)進(jìn)行的用戶做點(diǎn)事情：該技術(shù)值得一試，但沒(méi)有好處。 但是，如果您的應(yīng)用程序需要處理大量并行請(qǐng)求：我說(shuō)，去吧。

翻譯自: https://www.javacodegeeks.com/2015/03/java-io-benchmark-quasar-vs-async-forkjoinpool-vs-managedblock.html

quasar 異步回調(diào)

總結(jié)

以上是生活随笔為你收集整理的quasar 异步回调_Java IO基准测试：Quasar与异步ForkJoinPool与ManagedBlock的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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