fork join框架

Fork / Join框架在不同配置下如何工作？

就像即將到來的《星球大戰(zhàn)》（Star Wars）一樣，圍繞Java 8并行性的批評(píng)也充滿了興奮。 并行流的語法糖帶來了一些炒作，就像我們?cè)陬A(yù)告片中看到的新型光劍一樣。 現(xiàn)在，有了許多使用Java進(jìn)行并行處理的方法，我們希望了解性能優(yōu)勢(shì)和并行處理的危險(xiǎn)。 經(jīng)過260多次測(cè)試運(yùn)行后，從數(shù)據(jù)中獲得了一些新見解，我們希望在本文中與您分享。

分叉/加入：分叉喚醒

ExecutorService與Fork / Join Framework與并行流

很久以前，在一個(gè)遙遠(yuǎn)的星系中……。 我的意思是，大約10年前，并發(fā)只能通過3rd party庫在Java中使用。 隨后出現(xiàn)了Java 5，并在語言中引入了java.util.concurrent庫，該庫在Doug Lea的強(qiáng)烈影響下。 ExecutorService可用并為我們提供了一種處理線程池的直接方法。 當(dāng)然，java.util.concurrent一直在發(fā)展，并且在Java 7中引入了Fork / Join框架，該框架建立在ExecutorService線程池之上。 使用Java 8流，已經(jīng)為我們提供了使用Fork / Join的簡單方法，但對(duì)于許多開發(fā)人員來說仍然有點(diǎn)謎。 讓我們找出它們之間的比較。

我們完成了兩項(xiàng)任務(wù)，一項(xiàng)是CPU密集型任務(wù)，另一項(xiàng)是IO密集型任務(wù)，并使用相同的基本功能測(cè)試了4種不同的方案。 另一個(gè)重要因素是我們用于每個(gè)實(shí)現(xiàn)的線程數(shù)，因此我們也對(duì)其進(jìn)行了測(cè)試。 我們使用的機(jī)器有8個(gè)內(nèi)核 ，因此我們有4、8、16和32個(gè)線程的變種，以大致了解結(jié)果的發(fā)展方向。 對(duì)于每個(gè)任務(wù)，我們還嘗試了單線程解決方案，您不會(huì)在圖中看到它，因?yàn)閳?zhí)行起來要花費(fèi)更長的時(shí)間。 要詳細(xì)了解測(cè)試的運(yùn)行方式，您可以查看下面的基礎(chǔ)部分。 現(xiàn)在，讓我們開始吧。

用580萬行文本索引6GB文件

在此測(cè)試中，我們生成了一個(gè)巨大的文本文件，并為索引過程創(chuàng)建了類似的實(shí)現(xiàn)。 結(jié)果如下所示：

文件索引測(cè)試結(jié)果

**單線程執(zhí)行：176,267毫秒，或?qū)⒔?分鐘。
**請(qǐng)注意，圖形開始于20000毫秒。

1.更少的線程將使CPU未被使用，太多的線程將增加開銷

您在圖表中注意到的第一件事是結(jié)果開始采用的形狀–您僅從這4個(gè)數(shù)據(jù)點(diǎn)就可以了解每個(gè)實(shí)現(xiàn)的行為。 臨界點(diǎn)在8到16個(gè)線程之間，因?yàn)槟承┚€程在文件IO中處于阻塞狀態(tài)，并且添加比內(nèi)核更多的線程有助于更好地利用它們。 當(dāng)有32個(gè)線程進(jìn)入時(shí)，由于額外的開銷，性能會(huì)變差。

比亞軍快1秒：直接使用Fork / Join

除了語法糖（lambdas！我們沒有提到lambdas），我們已經(jīng)看到并行流的性能比Fork / Join和ExecutorService實(shí)現(xiàn)的更好。 6GB的文本在24.33秒內(nèi)被索引。 您可以在這里信任Java來提供最佳結(jié)果。

3.但是…并行流也表現(xiàn)最差：唯一的變化超過了30秒

這再次提醒您并行流如何降低您的速度。 假設(shè)這種情況發(fā)生在已經(jīng)運(yùn)行多線程應(yīng)用程序的計(jì)算機(jī)上。 在可用線程數(shù)量較少的情況下，直接使用Fork / Join實(shí)際上比通過并行流要好-5秒的差異，將這兩個(gè)線程進(jìn)行比較時(shí)大約要付出18％的代價(jià)。

4.不要使用圖片中帶有IO的默認(rèn)池大小

當(dāng)為并行流使用默認(rèn)池大小時(shí)，機(jī)器上相同數(shù)量的內(nèi)核（此處為8個(gè)內(nèi)核）比16線程版本的性能差了近2秒。 如果使用默認(rèn)池大小，則要加收7％的罰款。 發(fā)生這種情況的原因與阻塞IO線程有關(guān)。 還有更多的等待正在進(jìn)行，因此引入更多的線程可以使我們更多地使用所涉及的CPU內(nèi)核，而其他線程可以等待調(diào)度而不是空閑。

如何更改并行流的默認(rèn)Fork / Join池大小？ 您可以使用JVM參數(shù)更改常見的Fork / Join池大小：

-Djava.util.concurrent.ForkJoinPool.common.parallelism=16

（默認(rèn)情況下，所有Fork / Join任務(wù)都使用一個(gè)公共靜態(tài)池，其大小與內(nèi)核數(shù)相同。這樣做的好處是，通過在不使用期間為其他任務(wù)回收線程，從而減少了資源使用。）

或者…您可以使用此技巧并在自定義Fork / Join池中運(yùn)行并行流。 這將覆蓋通用的Fork / Join池的默認(rèn)用法，并允許您使用自己設(shè)置的池。 偷偷摸摸。 在測(cè)試中，我們使用了公共池。

5.單線程性能比最佳結(jié)果差7.25倍

并行性提供了7.25倍的改進(jìn)，并且考慮到該機(jī)器具有8個(gè)內(nèi)核，因此非常接近理論上的8倍預(yù)測(cè)！ 我們可以將其余的歸因于開銷。 話雖如此，即使我們測(cè)試的最慢的并行性實(shí)現(xiàn)（這次是具有4個(gè)線程的并行流（30.24sec）），其性能也比單線程解決方案（176.27sec）好5.8倍。

檢查數(shù)字是否為質(zhì)數(shù)

在下一輪測(cè)試中，我們完全消除了IO，并檢查了確定一個(gè)真正大的數(shù)字是否為素?cái)?shù)所需的時(shí)間。 多大？ 19位數(shù)字 。 1,530,692,068,127,007,263或換句話說：五百一十九億四千三百四十四萬億三千三百八十億八千八百八十三萬三千三百三十。 啊，讓我呼吸一下。 無論如何，除了運(yùn)行到其平方根之外，我們沒有使用任何優(yōu)化，因此即使我們的大數(shù)沒有除以2只是為了延長處理時(shí)間，我們也檢查了所有偶數(shù)。 劇透警告：這是首要的，因此每個(gè)實(shí)現(xiàn)都運(yùn)行相同數(shù)量的計(jì)算。

結(jié)果是這樣的：

素?cái)?shù)測(cè)試結(jié)果

**單線程執(zhí)行：118,127毫秒，或?qū)⒔?分鐘。
**請(qǐng)注意，圖形開始于20000毫秒

1. 8和16個(gè)線程之間的差異較小

與IO測(cè)試不同，這里沒有IO調(diào)用，因此8和16線程的性能幾乎是相似的，除了Fork / Join解決方案。 實(shí)際上，我們已經(jīng)運(yùn)行了更多的測(cè)試集，以確保由于這種“異常”而在這里獲得了良好的結(jié)果，但事實(shí)證明，一次又一次的相似。 我們很高興在下面的評(píng)論部分中聽到您對(duì)此的想法。

2.所有方法的最佳結(jié)果相似

我們看到所有實(shí)現(xiàn)都分享了大約28秒的相似最佳結(jié)果。 無論我們嘗試采用哪種方法，結(jié)果都相同。 這并不意味著我們對(duì)使用哪種方法都無所謂。 查看下一個(gè)見解。

3.并行流比其他實(shí)現(xiàn)更好地處理線程重載

這是更有趣的部分。 通過該測(cè)試，我們?cè)俅慰吹竭\(yùn)行16個(gè)線程的最高結(jié)果來自使用并行流。 此外，在此版本中，使用并行流是線程號(hào)所有變體的一個(gè)好選擇。

4.單線程性能比最佳結(jié)果低4.2倍

此外，在運(yùn)行計(jì)算密集型任務(wù)時(shí)使用并行性的好處幾乎比使用文件IO的IO測(cè)試要差2倍。 這是有道理的，因?yàn)樗荂PU密集型測(cè)試，與之前的測(cè)試不同，我們可以通過減少內(nèi)核等待被IO阻塞的線程的時(shí)間來獲得額外的好處。

結(jié)論

我建議您從源頭上了解何時(shí)使用并行流的更多信息，并在您使用Java進(jìn)行并行化時(shí)隨時(shí)進(jìn)行仔細(xì)的判斷。 最好的方法是在暫存環(huán)境中運(yùn)行與這些測(cè)試類似的測(cè)試，在此環(huán)境中您可以嘗試并更好地了解要面對(duì)的挑戰(zhàn)。 您必須注意的因素當(dāng)然是運(yùn)行的硬件（以及要測(cè)試的硬件）以及應(yīng)用程序中的線程總數(shù)。 這包括公用的Fork / Join池和團(tuán)隊(duì)中其他開發(fā)人員正在處理的代碼。 因此，在添加自己的并行性之前，請(qǐng)嘗試檢查它們并獲得應(yīng)用程序的完整視圖。

基礎(chǔ)工作

為了運(yùn)行此測(cè)試，我們使用了具有8個(gè)vCPU和15GB RAM的EC2 c3.2xlarge實(shí)例。 vCPU意味著存在超線程，因此實(shí)際上我們?cè)谶@里有4個(gè)物理內(nèi)核，每個(gè)物理內(nèi)核都像2個(gè)內(nèi)核一樣工作。就OS調(diào)度程序而言，我們?cè)谶@里有8個(gè)內(nèi)核。 為了盡可能使它公平，每個(gè)實(shí)現(xiàn)都運(yùn)行了10次，并且我們采用了運(yùn)行2到9的平均運(yùn)行時(shí)間。這是260次測(cè)試運(yùn)行，！ 另一重要的是處理時(shí)間。 我們選擇的任務(wù)要花費(fèi)20秒鐘以上的時(shí)間，因此差異更容易發(fā)現(xiàn)，并且不受外部因素的影響。

下一步是什么？

原始結(jié)果可在此處獲得 ，代碼在GitHub上 。 請(qǐng)隨時(shí)修改它，并讓我們知道您得到什么樣的結(jié)果。 如果您對(duì)我們錯(cuò)過的結(jié)果有更多有趣的見解或解釋，我們很樂意閱讀并添加到帖子中。

翻譯自: https://www.javacodegeeks.com/2015/01/forkjoin-framework-vs-parallel-streams-vs-executorservice-the-ultimate-forkjoin-benchmark.html

fork join框架

總結(jié)

以上是生活随笔為你收集整理的fork join框架_Fork / Join框架vs.并行流vs.ExecutorService：最终的Fork / Join基准的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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