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

Arien Kock是Java軟件工程師。 他喜歡單口喜劇，并且曾經是街頭霸王的競爭者。

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

我認為Quarar有很大的潛力。 除了允許更多數量的并行操作之外，Quasar的光纖還允許OS線程不是一對一的映射，它還使程序員能夠以同步方式（使用延續 ）來編寫代碼。 這比普通的異步風格的代碼往往會帶來回調的痕跡使解釋和推理代碼更加容易。 對于輕量級線程的性能優勢，我考慮暫停綠色線程的性能的提高/纖維與停車操作系統線程非常成熟 。 在這篇Takipi博客文章的啟發下 ，我對Quasar在IO場景中的表現與替代品的表現感到好奇。 所以我做了一個基準。

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

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

設置

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

結果

通過5次熱身迭代和15個真實樣本，我相信這是非常準確的。

差異遠在誤差范圍之內，我相信可以肯定地說它們是相等的。 運行堆棧分析器僅顯示托管阻塞和非阻塞（Quasar和Async FJP）類型之間的差異，這會產生非常不同的調用堆棧。 我創建了一個使用Socket進行相同操作的基準測試，但是我很確定實現中存在錯誤。 如果有人想看一下代碼，請放心。

我預計托管塊會變慢，因為當無法保證FJP上的并行性時，它將分配額外的線程，使用計算任務肯定是這種情況。 在運行該基準測試時，我什至無法正常啟動VisualVM。 大量的線程使其加載非常緩慢。 盡管頻繁分配線程，但沒有區別。 類星體也是如此。 暫掛光纖的開銷（保留執行進程的當前狀態以釋放CPU內核的操作）不會引起任何明顯的延遲。 在“引人注目的”是關鍵的地方……

結論

面對IO，這三種實現的速度差異不明顯。 我是否實現了滅火是沒有關系的，因為CPU是瓶頸，因為在所有三種實現中，常規（非IO）代碼都將以相同的速度和相同的并行度執行。 這是因為Quasar不會進行任何上下文切換，除非光纖實際阻塞了。 如果光纖花費太長時間執行而沒有光纖阻塞，類星體甚至會發出警告。 似乎三種處理IO的性能均相同，這意味著對于這種類型的應用程序，在這三種類型之間進行選擇將是一個問題。 但是，我認為這只是部分正確。 在回調樣式和阻止樣式之間，如果我要做的是同時處理8個文件，則可以清楚地選擇阻止樣式。 它更容易掌握。 接下來，在托管塊（創建更多線程）和光纖塊之間進行選擇，托管塊的工作量最少。 案件尚未完全結案，但是……

潛伏

在客戶端連接可以長時間保持打開的Web服務器中（例如，當我們等待緩慢的客戶端和/或正在從數據庫中獲取數據時），在事務期間阻塞線程可能會導致線程饑餓。 這是Quasar真正發揮作用的地方，這要歸功于將許多用戶空間線程復用到少量OS線程上。 然后有...

使用Quasar的（當前）“困難”

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

IO光纖：是或否

當您要做的只是具有高吞吐量和低并行度的連續IO時，基準測試不會顯示使用光纖的任何代價。 使用Quasar所做的額外工作（就額外的編碼和配置而言）是一系列一次性任務，（在我看來）這可以忽略不計。 Pulsar提供了一組很好的集成（盡管JDBC有點不足）。 使用這些和您自己的應用程序，您可以創建一個IO繁重的應用程序（例如Web應用程序），該應用程序具有一個用于接受連接的池和一個或多個用于處理后端調用的池。 您最終得到的是線程池，這些線程在后臺將任務相互傳遞，而您的邏輯仍然以同步的方式從上到下讀取，最后是return語句。

如果像大多數小型應用程序一樣，您最多只能為數百名同時進行的用戶做點事情：該技術值得一試，但沒有好處。 但是，如果您的應用程序需要處理大量并行請求：我說，去吧。

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

總結

以上是生活随笔為你收集整理的Java IO基准测试：Quasar与异步ForkJoinPool与ManagedBlock的全部內容，希望文章能夠幫你解決所遇到的問題。

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