轉(zhuǎn)載自?http://www.importnew.com/27334.html

Doug Lea 大神關(guān)于Java 7引入的他寫的Fork/Join框架的論文。

響應(yīng)式編程（Reactive Programming / RP）作為一種范式在整個業(yè)界正在逐步受到認(rèn)可和落地，是對過往系統(tǒng)的業(yè)務(wù)需求理解梳理之后對系統(tǒng)技術(shù)設(shè)計/架構(gòu)模式的提升總結(jié)。Java作為一個成熟平臺，對于趨勢一向有些穩(wěn)健的接納和跟進(jìn)能力，有著令人驚嘆的生命活力：

Java 7提供了ForkJoinPool，支持了Java 8提供的Stream（Reactive Stream是RP的一個核心組件）。
另外Java 8還提供了Lamda（有效地表達(dá)和使用RP需要FP的語言構(gòu)件和理念）。
有了前面的這些穩(wěn)健但不失時機(jī)的準(zhǔn)備，在Java 9中提供了面向RP的Flow API，為Java圈子提供了官方的RP API，標(biāo)志著RP由集市式的自由探索階段 向 教堂式的統(tǒng)一使用的轉(zhuǎn)變。

通過上面這些說明，可以看到ForkJoinPool的基礎(chǔ)重要性。

對了，另外提一下Java 9的Flow API的@author也是 Doug Lee 哦～

PS：基于Alex/蕭歡 翻譯、方騰飛 校對的譯文稿：Java Fork Join 框架，補(bǔ)譯『結(jié)論』之后3節(jié)，調(diào)整了格式和一些用詞，整理成完整的譯文。譯文源碼在GitHub的這個倉庫中，可以提交Issue/Fork后提交代碼來建議/指正。

0. 摘要

這篇論文描述了Fork/Join框架的設(shè)計、實現(xiàn)以及性能，這個框架通過（遞歸的）把問題劃分為子任務(wù)，然后并行的執(zhí)行這些子任務(wù)，等所有的子任務(wù)都結(jié)束的時候，再合并最終結(jié)果的這種方式來支持并行計算編程。總體的設(shè)計參考了為Cilk設(shè)計的work-stealing框架。就設(shè)計層面來說主要是圍繞如何高效的去構(gòu)建和管理任務(wù)隊列以及工作線程來展開的。性能測試的數(shù)據(jù)顯示良好的并行計算程序?qū)嵘蟛糠謶?yīng)用，同時也暗示了一些潛在的可以提升的空間。

校注1： Cilk是英特爾Cilk語言。英特爾C++編輯器的新功能Cilk語言擴(kuò)展技術(shù)，為C/C++語言增加了細(xì)粒度任務(wù)支持，使其為新的和現(xiàn)有的軟件增加并行性來充分發(fā)掘多處理器能力變得更加容易。

1. 簡介

Fork/Join并行方式是獲取良好的并行計算性能的一種最簡單同時也是最有效的設(shè)計技術(shù)。Fork/Join并行算法是我們所熟悉的分治算法的并行版本，典型的用法如下：

1 2 3 4 5 6 7 8 9 10 11 12 13 14

Result solve(Problem problem) { ? ????if (problem is small) { ? ????????directly solve problem ? ????} else { ? ????????split problem into independent parts ????????fork new subtasks to solve each part ????????join all subtasks ????????compose result from subresults ????} }

fork操作將會啟動一個新的并行Fork/Join子任務(wù)。join操作會一直等待直到所有的子任務(wù)都結(jié)束。Fork/Join算法，如同其他分治算法一樣，總是會遞歸的、反復(fù)的劃分子任務(wù)，直到這些子任務(wù)可以用足夠簡單的、短小的順序方法來執(zhí)行。

一些相關(guān)的編程技術(shù)和實例在《Java并發(fā)編程 —— 設(shè)計原則與模式 第二版》[7] 4.4章節(jié)中已經(jīng)討論過。這篇論文將討論FJTask的設(shè)計（第2節(jié)）、實現(xiàn)（第3節(jié)）以及性能（第4節(jié)），它是一個支持并行編程方式的Java™框架。FJTask 作為util.concurrent軟件包的一部分，目前可以在 http://gee.cs.oswego.edu/ 獲取到。

2. 設(shè)計

Fork/Join程序可以在任何支持以下特性的框架之上運行：框架能夠讓構(gòu)建的子任務(wù)并行執(zhí)行，并且擁有一種等待子任務(wù)運行結(jié)束的機(jī)制。然而，java.lang.Thread類（同時也包括POSIX pthread，這些也是Java線程所基于的基礎(chǔ)）對Fork/Join程序來說并不是最優(yōu)的選擇：

Fork/Join任務(wù)對同步和管理有簡單的和常規(guī)的需求。相對于常規(guī)的線程來說，Fork/Join任務(wù)所展示的計算布局將會帶來更加靈活的調(diào)度策略。例如，Fork/Join任務(wù)除了等待子任務(wù)外，其他情況下是不需要阻塞的。因此傳統(tǒng)的用于跟蹤記錄阻塞線程的代價在這種情況下實際上是一種浪費。
對于一個合理的基礎(chǔ)任務(wù)粒度來說，構(gòu)建和管理一個線程的代價甚至可以比任務(wù)執(zhí)行本身所花費的代價更大。盡管粒度是應(yīng)該隨著應(yīng)用程序在不同特定平臺上運行而做出相應(yīng)調(diào)整的。但是超過線程開銷的極端粗粒度會限制并行的發(fā)揮。
簡而言之，Java標(biāo)準(zhǔn)的線程框架對Fork/Join程序而言太笨重了。但是既然線程構(gòu)成了很多其他的并發(fā)和并行編程的基礎(chǔ)，完全消除這種代價或者為了這種方式而調(diào)整線程調(diào)度是不可能（或者說不切實際的）。

盡管這種思想已經(jīng)存在了很長時間了，但是第一個發(fā)布的能系統(tǒng)解決這些問題的框架是Cilk[5]。Cilk和其他輕量級的框架是基于操作系統(tǒng)的基本的線程和進(jìn)程機(jī)制來支持特殊用途的Fork/Join程序。這種策略同樣適用于Java，盡管Java線程是基于低級別的操作系統(tǒng)的能力來實現(xiàn)的。創(chuàng)造這樣一個輕量級的執(zhí)行框架的主要優(yōu)勢是能夠讓Fork/Join程序以一種更直觀的方式編寫，進(jìn)而能夠在各種支持JVM的系統(tǒng)上運行。

FJTask框架是基于Cilk設(shè)計的一種演變。其他的類似框架有Hood[4]、Filaments[8]、Stackthreads[10]以及一些依賴于輕量級執(zhí)行任務(wù)的相關(guān)系統(tǒng)。所有這些框架都采用和操作系統(tǒng)把線程映射到CPU上相同的方式來把任務(wù)映射到線程上。只是他們會使用Fork/Join程序的簡單性、常規(guī)性以及一致性來執(zhí)行這種映射。盡管這些框架都能適應(yīng)不能形式的并行程序，他們優(yōu)化了Fork/Join的設(shè)計：

• 一組工作者線程池是準(zhǔn)備好的。每個工作線程都是標(biāo)準(zhǔn)的（『重量級』）處理存放在隊列中任務(wù)的線程（這地方指的是Thread類的子類FJTaskRunner的實例對象）。通常情況下，工作線程應(yīng)該與系統(tǒng)的處理器數(shù)量一致。對于一些原生的框架例如說Cilk，他們首先將映射成內(nèi)核線程或者是輕量級的進(jìn)程，然后再在處理器上面運行。在Java中，虛擬機(jī)和操作系統(tǒng)需要相互結(jié)合來完成線程到處理器的映射。然后對于計算密集型的運算來說，這種映射對于操作系統(tǒng)來說是一種相對簡單的任務(wù)。任何合理的映射策略都會導(dǎo)致線程映射到不同的處理器。
• 所有的Fork/Join任務(wù)都是輕量級執(zhí)行類的實例，而不是線程實例。在Java中，獨立的可執(zhí)行任務(wù)必須要實現(xiàn)Runnable接口并重寫run方法。在FJTask框架中，這些任務(wù)將作為子類繼承FJTask而不是Thread，它們都實現(xiàn)了Runnable接口。（對于上面兩種情況來說，一個類也可以選擇實現(xiàn)Runnable接口，類的實例對象既可以在任務(wù)中執(zhí)行也可以在線程中執(zhí)行。因為任務(wù)執(zhí)行受到來自FJTask方法嚴(yán)厲規(guī)則的制約，子類化FJTask相對來說更加方便，也能夠直接調(diào)用它們。）
• 我們將采用一個特殊的隊列和調(diào)度原則來管理任務(wù)并通過工作線程來執(zhí)行任務(wù)。這些機(jī)制是由任務(wù)類中提供的相關(guān)方式實現(xiàn)的：主要是由fork、join、isDone（一個結(jié)束狀態(tài)的標(biāo)示符），和一些其他方便的方法，例如調(diào)用coInvoke來分解合并兩個或兩個以上的任務(wù)。
• 一個簡單的控制和管理類（這里指的是FJTaskRunnerGroup）來啟動工作線程池，并初始化執(zhí)行一個由正常的線程調(diào)用所觸發(fā)的Fork/Join任務(wù)（就類似于Java程序中的main方法）。

作為一個給程序員演示這個框架如何運行的標(biāo)準(zhǔn)實例，這是一個計算法斐波那契函數(shù)的類。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43

class Fib extends FJTask { ????static final int threshold = 13; ????volatile int number; // arg/result ? ????Fib(int n) { ????????number = n; ????} ? ????int getAnswer() { ????????if (!isDone()) ????????????throw new IllegalStateException(); ????????return number; ????} ? ????public void run() { ????????int n = number; ????????if (n <= threshold) // granularity ctl ????????????number = seqFib(n); ????????else { ????????????Fib f1 = new Fib(n - 1); ????????????Fib f2 = new Fib(n - 2); ????????????coInvoke(f1, f2); ????????????number = f1.number + f2.number; ????????} ????} ? ????public static void main(String[] args) { ????????try { ????????????int groupSize = 2; // for example ????????????FJTaskRunnerGroup group = new FJTaskRunnerGroup(groupSize); ????????????Fib f = new Fib(35); // for example ????????????group.invoke(f); ????????????int result = f.getAnswer(); ????????????System.out.println("Answer: " + result); ????????} catch (InterruptedException ex) { ????????} ????} ? ????int seqFib(int n) { ????????if (n <= 1) return n; ????????else return seqFib(n ? 1) + seqFib(n ? 2); ????} }

這個版本在第4節(jié)中所提到的平臺上的運行速度至少比每個任務(wù)都在Thread類中運行快30倍。在保持性能的同時這個程序仍然維持著Java多線程程序的可移植性。對程序員來說通常有兩個參數(shù)值的他們關(guān)注：

• 對于工作線程的創(chuàng)建數(shù)量，通常情況下可以與平臺所擁有的處理器數(shù)量保持一致（或者更少，用于處理其他相關(guān)的任務(wù)，或者有些情況下更多，來提升非計算密集型任務(wù)的性能）。
• 一個粒度參數(shù)代表了創(chuàng)建任務(wù)的代價會大于并行化所帶來的潛在的性能提升的臨界點。這個參數(shù)更多的是取決于算法而不是平臺。通常在單處理器上運行良好的臨界點，在多處理器平臺上也會發(fā)揮很好的效果。作為一種附帶的效益，這種方式能夠與Java虛擬機(jī)的動態(tài)編譯機(jī)制很好的結(jié)合，而這種機(jī)制在對小塊方法的優(yōu)化方面相對于單塊的程序來說要好。這樣，加上數(shù)據(jù)本地化的優(yōu)勢，Fork/Join算法的性能即使在單處理器上面的性能都較其他算法要好。

2.1 work?stealing

Fork/Join框架的核心在于輕量級調(diào)度機(jī)制。FJTask采用了Cilk的work-stealing所采用的基本調(diào)度策略：

• 每一個工作線程維護(hù)自己的調(diào)度隊列中的可運行任務(wù)。
• 隊列以雙端隊列的形式被維護(hù)（注：deques通常讀作『decks』），不僅支持后進(jìn)先出 —— LIFO的push和pop操作，還支持先進(jìn)先出 —— FIFO的take操作。
• 對于一個給定的工作線程來說，任務(wù)所產(chǎn)生的子任務(wù)將會被放入到工作者自己的雙端隊列中。
• 工作線程使用后進(jìn)先出 —— LIFO（最新的元素優(yōu)先）的順序，通過彈出任務(wù)來處理隊列中的任務(wù)。
• 當(dāng)一個工作線程的本地沒有任務(wù)去運行的時候，它將使用先進(jìn)先出 —— FIFO的規(guī)則嘗試隨機(jī)的從別的工作線程中拿（『竊取』）一個任務(wù)去運行。
• 當(dāng)一個工作線程觸及了join操作，如果可能的話它將處理其他任務(wù)，直到目標(biāo)任務(wù)被告知已經(jīng)結(jié)束（通過isDone方法）。所有的任務(wù)都會無阻塞的完成。
• 當(dāng)一個工作線程無法再從其他線程中獲取任務(wù)和失敗處理的時候，它就會退出（通過yield、sleep和/或者優(yōu)先級調(diào)整，參考第3節(jié)）并經(jīng)過一段時間之后再度嘗試直到所有的工作線程都被告知他們都處于空閑的狀態(tài)。在這種情況下，他們都會阻塞直到其他的任務(wù)再度被上層調(diào)用。

使用后進(jìn)先出 —— LIFO用來處理每個工作線程的自己任務(wù)，但是使用先進(jìn)先出 —— FIFO規(guī)則用于獲取別的任務(wù)，這是一種被廣泛使用的進(jìn)行遞歸Fork/Join設(shè)計的一種調(diào)優(yōu)手段。引用[5]討論了詳細(xì)討論了里面的細(xì)節(jié)。

讓竊取任務(wù)的線程從隊列擁有者相反的方向進(jìn)行操作會減少線程競爭。同樣體現(xiàn)了遞歸分治算法的大任務(wù)優(yōu)先策略。因此，更早期被竊取的任務(wù)有可能會提供一個更大的單元任務(wù)，從而使得竊取線程能夠在將來進(jìn)行遞歸分解。

作為上述規(guī)則的一個后果，對于一些基礎(chǔ)的操作而言，使用相對較小粒度的任務(wù)比那些僅僅使用粗粒度劃分的任務(wù)以及那些沒有使用遞歸分解的任務(wù)的運行速度要快。盡管相關(guān)的少數(shù)任務(wù)在大多數(shù)的Fork/Join框架中會被其他工作線程竊取，但是創(chuàng)建許多組織良好的任務(wù)意味著只要有一個工作線程處于可運行的狀態(tài)，那么這個任務(wù)就有可能被執(zhí)行。

3. 實現(xiàn)

這個框架是由大約800行純Java代碼組成，主要的類是FJTaskRunner，它是java.lang.Thread的子類。FJTask自己僅僅維持一個關(guān)于結(jié)束狀態(tài)的布爾值，所有其他的操作都是通過當(dāng)前的工作線程來代理完成的。JFTaskRunnerGroup類用于創(chuàng)建工作線程，維護(hù)一些共享的狀態(tài)（例如：所有工作線程的標(biāo)示符，在竊取操作時需要），同時還要協(xié)調(diào)啟動和關(guān)閉。

更多實現(xiàn)的細(xì)節(jié)文檔可以在util.concurrent并發(fā)包中查看。這一節(jié)只著重討論兩類問題以及在實現(xiàn)這個框架的時候所形成的一些解決方案：支持高效的雙端列表操作（push、pop和take）， 并且當(dāng)工作線程在嘗試獲取新的任務(wù)時維持竊取的協(xié)議。

3.1 雙端隊列

（校注：雙端隊列中的元素可以從兩端彈出，其限定插入和刪除操作在隊列的兩端進(jìn)行。）

為了能夠獲得高效以及可擴(kuò)展的執(zhí)行任務(wù)，任務(wù)管理需要越快越好。創(chuàng)建、發(fā)布、和彈出（或者出現(xiàn)頻率很少的獲取）任務(wù)在順序編程模式中會引發(fā)程序調(diào)用開銷。更低的開銷可以使得程序員能夠構(gòu)建更小粒度的任務(wù)，最終也能更好的利用并行所帶來的益處。

Java虛擬機(jī)會負(fù)責(zé)任務(wù)的內(nèi)存分配。Java垃圾回收器使我們不需要再去編寫一個特殊的內(nèi)存分配器去維護(hù)任務(wù)。相對于其他語言的類似框架，這個原因使我們大大降低了實現(xiàn)FJTask的復(fù)雜性以及所需要的代碼數(shù)。

雙端隊列的基本結(jié)構(gòu)采用了很常規(guī)的一個結(jié)構(gòu) —— 使用一個數(shù)組（盡管是可變長的）來表示每個隊列，同時附帶兩個索引：top索引就類似于數(shù)組中的棧指針，通過push和pop操作來改變。base索引只能通過take操作來改變。鑒于FJTaskRunner操作都是無縫的綁定到雙端隊列的細(xì)節(jié)之中，（例如，fork直接調(diào)用push），所以這個數(shù)據(jù)結(jié)構(gòu)直接放在類之中，而不是作為一個單獨的組件。

但是雙端隊列的元素會被多線程并發(fā)的訪問，在缺乏足夠同步的情況下，而且單個的Java數(shù)組元素也不能聲明為volatile變量（校注：聲明成volatile的數(shù)組，其元素并不具備volatile語意），每個數(shù)組元素實際上都是一個固定的引用，這個引用指向了一個維護(hù)著單個volatile引用的轉(zhuǎn)發(fā)對象。一開始做出這個決定主要是考慮到Java內(nèi)存模型的一致性。但是在這個級別它所需要的間接尋址被證明在一些測試過的平臺上能夠提升性能。可能是因為訪問鄰近的元素而降低了緩存爭用，這樣內(nèi)存里面的間接尋址會更快一點。

實現(xiàn)雙端隊列的主要挑戰(zhàn)來自于同步和他的撤銷。盡管在Java虛擬機(jī)上使用經(jīng)過優(yōu)化過的同步工具，對于每個push和pop操作都需要獲取鎖還是讓這一切成為性能瓶頸。然后根據(jù)以下的觀察結(jié)果我們可以修改Clik中的策略，從而為我們提供一種可行的解決方案：

• push和pop操作僅可以被工作線程的擁有者所調(diào)用。
• 對take的操作很容易會由于竊取任務(wù)線程在某一時間對take操作加鎖而限制。（雙端隊列在必要的時間也可以禁止take操作。）這樣，控制沖突將被降低為兩個部分同步的層次。
• pop和take操作只有在雙端隊列為空的時候才會發(fā)生沖突，否則的話，隊列會保證他們在不同的數(shù)組元素上面操作。

把top和base索引定義為volatile變量可以保證當(dāng)隊列中元素不止一個時，pop和take操作可以在不加鎖的情況下進(jìn)行。這是通過一種類似于Dekker算法來實現(xiàn)的。當(dāng)push預(yù)遞減到top時：

1	if (–top >= base) ...

和take預(yù)遞減到base時：

1	if (++base < top) ...

在上述每種情況下他們都通過比較兩個索引來檢查這樣是否會導(dǎo)致雙端隊列變成一個空隊列。一個不對稱的規(guī)則將用于防止?jié)撛诘臎_突：pop會重新檢查狀態(tài)并在獲取鎖之后繼續(xù)（對take所持有的也一樣），直到隊列真的為空才退出。而take操作會立即退出，特別是當(dāng)嘗試去獲得另外一個任務(wù)。與其他類似使用Clik的THE協(xié)議一樣，這種不對稱性是唯一重要的改變。

使用volatile變量索引push操作在隊列沒有滿的情況下不需要同步就可以進(jìn)行。如果隊列將要溢出，那么它首先必須要獲得隊列鎖來重新設(shè)置隊列的長度。其他情況下，只要確保top操作排在隊列數(shù)組槽盛在抑制干涉帶之后更新。

在隨后的初始化實現(xiàn)中，發(fā)現(xiàn)有好幾種JVM并不符合Java內(nèi)存模型中正確讀取寫入的volatile變量的規(guī)則。作為一個工作區(qū)，pop操作在持有鎖的情況下重試的條件已經(jīng)被調(diào)整為：如果有兩個或者更少的元素，并且take操作加了第二把鎖以確保內(nèi)存屏障效果，那么重試就會被觸發(fā)。只要最多只有一個索引被擁有者線程丟失這就是滿足的，并且只會引起輕微的性能損耗。

3.2 搶斷和閑置

在搶斷式工作框架中，工作線程對于他們所運行的程序?qū)ν降囊笠粺o所知。他們只是構(gòu)建、發(fā)布、彈出、獲取、管理狀態(tài)和執(zhí)行任務(wù)。這種簡單的方案使得當(dāng)所有的線程都擁有很多任務(wù)需要去執(zhí)行的時候，它的效率很高。然而這種方式是有代價的，當(dāng)沒有足夠的工作的時候它將依賴于試探法。也就是說，在啟動一個主任務(wù)，直到它結(jié)束，在有些Fork/Join算法中都使用了全面停止的同步指針。

主要的問題在于當(dāng)一個工作線程既無本地任務(wù)也不能從別的線程中搶斷任務(wù)時怎么辦。如果程序運行在專業(yè)的多核處理器上面，那么可以依賴于硬件的忙等待自旋循環(huán)的去嘗試搶斷一個任務(wù)。然而，即使這樣，嘗試搶斷還是會增加競爭，甚至?xí)?dǎo)致那些不是閑置的工作線程降低效率（由于鎖協(xié)議，3.1節(jié)中）。除此之外，在一個更適合此框架運行的場景中，操作系統(tǒng)應(yīng)該能夠很自信的去運行那些不相關(guān)并可運行的進(jìn)程和線程。

Java中并沒有十分健壯的工作來保證這個，但是在實際中它往往是可以讓人接受的。一個搶斷失敗的線程在嘗試另外的搶斷之前會降低自己的優(yōu)先級，在嘗試搶斷之間執(zhí)行Thread.yeild操作，然后將自己的狀態(tài)在FJTaskRunnerGroup中設(shè)置為不活躍的。他們會一直阻塞直到有新的主線程。其他情況下，在進(jìn)行一定的自旋次數(shù)之后，線程將進(jìn)入休眠階段，他們會休眠而不是放棄搶斷。強(qiáng)化的休眠機(jī)制會給人造成一種需要花費很長時間去劃分任務(wù)的假象。但是這似乎是最好的也是通用的折中方案。框架的未來版本也許會支持額外的控制方法，以便于讓程序員在感覺性能受到影響時可以重寫默認(rèn)的實現(xiàn)。

4. 性能

如今，隨著編譯器與Java虛擬機(jī)性能的不斷提升，性能測試結(jié)果也僅僅只能適用一時。但是，本節(jié)中所提到的測試結(jié)果數(shù)據(jù)卻能揭示Fork/Join框架的基本特性。

下面表格中簡單介紹了在下文將會用到的一組Fork/Join測試程序。這些程序是從util.concurrent包里的示例代碼改編而來，用來展示Fork/Join框架在解決不同類型的問題模型時所表現(xiàn)的差異，同時得到該框架在一些常見的并行測試程序上的測試結(jié)果。

程序	描述
Fib（菲波那契數(shù)列）	如第2節(jié)所描述的Fibonnaci程序，其中參數(shù)值為47閥值為13
Integrate（求積分）	使用遞歸高斯求積對公式??求-47到48的積分，i?為1到5之間的偶數(shù)
Micro（求微分）	對一種棋盤游戲?qū)ふ易詈玫囊苿硬呗?#xff0c;每次計算出后面四次移動
Sort（排序）	使用合并/快速排序算法對1億數(shù)字進(jìn)行排序（基于Cilk算法）
MM（矩陣相乘）	2048 X 2048的double類型的矩陣進(jìn)行相乘
LU（矩陣分解）	4096 X 4096的double類型的矩陣進(jìn)行分解
Jacobi（雅克比迭代法）	對一個4096 X 4096的double矩陣使用迭代方法進(jìn)行矩陣松弛，迭代次數(shù)上限為100

下文提到的主要的測試，其測試程序都是運行在Sun Enterprise 10000服務(wù)器上，該服務(wù)器擁有30個CPU，操作系統(tǒng)為Solaris 7系統(tǒng)，運行Solaris商業(yè)版1.2 JVM（2.2.2_05發(fā)布版本的一個早期版本）。同時，Java虛擬機(jī)的關(guān)于線程映射的環(huán)境參數(shù)選擇為『bound threads』（譯者注：XX:+UseBoundThreads，綁定用戶級別的線程到內(nèi)核線程，只與Solaris有關(guān)），而關(guān)于虛擬機(jī)的內(nèi)存參數(shù)設(shè)置在4.2章節(jié)討論。另外，需要注意的是下文提到的部分測試則是運行在擁有4 CPU的Sun Enterprise 450服務(wù)器上。

為了降低定時器粒度以及Java虛擬機(jī)啟動因素對測試結(jié)果的影響，測試程序都使用了數(shù)量巨大的輸入?yún)?shù)。而其它一些啟動因素我們通過在啟動定時器之前先運行初始化任務(wù)來進(jìn)行屏蔽。所得到的測試結(jié)果數(shù)據(jù)，大部分都是在三次測試結(jié)果的中間值，然而一些測試數(shù)據(jù)僅僅來自一次運行結(jié)果（包括4.2 ~ 4.4章節(jié)很多測試），因此這些測試結(jié)果會有噪音表現(xiàn)。

4.1 加速效果

通過使用不同數(shù)目（1 ~ 30）的工作線程對同一問題集進(jìn)行測試，用來得到框架的擴(kuò)展性測試結(jié)果。雖然我們無法保證Java虛擬機(jī)是否總是能夠?qū)⒚恳粋€線程映射到不同的空閑CPU上，同時，我們也沒有證據(jù)來證明這點。有可能映射一個新的線程到CPU的延遲會隨著線程數(shù)目的增加而變大，也可能會隨不同的系統(tǒng)以及不同的測試程序而變化。但是，所得到的測試結(jié)果的確顯示出增加線程的數(shù)目確實能夠增加使用的CPU的數(shù)目。

加速比通常表示為 Timen / Time1。如上圖所示，其中求積分的程序表現(xiàn)出最好的加速比（30個線程的加速比為28.2），表現(xiàn)最差的是矩陣分解程序（30線程是加速比只有15.35）

另一種衡量擴(kuò)展性的依據(jù)是：任務(wù)執(zhí)行率，及執(zhí)行一個單獨任務(wù)（這里的任務(wù)有可能是遞歸分解節(jié)點任務(wù)也可能是根節(jié)點任務(wù)）所開銷的平均時間。下面的數(shù)據(jù)顯示出一次性執(zhí)行各個程序所得到的任務(wù)執(zhí)行率數(shù)據(jù)。很明顯，單位時間內(nèi)執(zhí)行的任務(wù)數(shù)目應(yīng)該是固定常量。然而事實上，隨著線程數(shù)目增加，所得到的數(shù)據(jù)會表現(xiàn)出輕微的降低，這也表現(xiàn)出其一定的擴(kuò)展性限制。這里需要說明的是，之所以任務(wù)執(zhí)行率在各個程序上表現(xiàn)的巨大差異，是因其任務(wù)粒度的不同造成的。任務(wù)執(zhí)行率最小的程序是Fib（菲波那契數(shù)列），其閥值設(shè)置為13，在30個線程的情況下總共完成了280萬個單元任務(wù)。

導(dǎo)致這些程序的任務(wù)完成率沒有表現(xiàn)為水平直線的因素有四個。其中三個對所有的并發(fā)框架來說都是普遍原因，所以，我們就從對FJTask框架（相對于Cilk等框架）所特有的因素說起，即垃圾回收。

4.2 垃圾回收

總的來說，現(xiàn)在的垃圾回收機(jī)制的性能是能夠與Fork/Join框架所匹配的：Fork/Join程序在運行時會產(chǎn)生巨大數(shù)量的任務(wù)單元，然而這些任務(wù)在被執(zhí)行之后又會很快轉(zhuǎn)變?yōu)閮?nèi)存垃圾。相比較于順序執(zhí)行的單線程程序，在任何時候，其對應(yīng)的F’
;%?Zh8HE’
;%?Zh最多p倍的內(nèi)存空間（其中p為線程數(shù)目）。基于分代的半空間拷貝垃圾回收器（也就是本文中測試程序所使用的Java虛擬機(jī)所應(yīng)用的垃圾回收器）能夠很好的處理這種情況，因為這種垃圾回收機(jī)制在進(jìn)行內(nèi)存回收的時候僅僅拷貝非垃圾內(nèi)存單元。這樣做，就避免了在手工并發(fā)內(nèi)存管理上的一個復(fù)雜的問題，即跟蹤那些被一個線程分配卻在另一個線程中使用的內(nèi)存單元。這種垃圾回收機(jī)制并不需要知道內(nèi)存分配的源頭，因此也就無需處理這個棘手的問題。

這種垃圾回收機(jī)制優(yōu)勢的一個典型體現(xiàn)：使用這種垃圾回收機(jī)制，四個線程運行的Fib程序耗時僅為5.1秒鐘，而如果在Java虛擬機(jī)設(shè)置關(guān)閉代拷貝回收（這種情況下使用的就是標(biāo)記清除（mark?sweep）垃圾回收機(jī)制了），耗時需要9.1秒鐘。

然而，只有內(nèi)存使用率只有達(dá)到一個很高的值的情況下，垃圾回收機(jī)制才會成為影響擴(kuò)展性的一個因素，因為這種情況下，虛擬機(jī)必須經(jīng)常停止其他線程來進(jìn)行垃圾回收。以下的數(shù)據(jù)顯示出在三種不同的內(nèi)存設(shè)置下（Java虛擬機(jī)支持通過額外的參數(shù)來設(shè)置內(nèi)存參數(shù)），加速比所表現(xiàn)出的差異：默認(rèn)的4M的半空間，64M的半空間，另外根據(jù)線程數(shù)目按照公式（2 + 2p）M設(shè)置半空間。使用較小的半空間，在額外線程導(dǎo)致垃圾回收率攀高的情況下，停止其他線程并進(jìn)行垃圾回收的開銷開始影響加封。

鑒于上面的結(jié)果，我們使用64M的半空間作為其他測試的運行標(biāo)準(zhǔn)。其實設(shè)置內(nèi)存大小的一個更好的策略就是根據(jù)每次測試的實際線程數(shù)目來確定。（正如上面的測試數(shù)據(jù)，我們發(fā)現(xiàn)這種情況下，加速比會表現(xiàn)的更為平滑）。相對的另一方面，程序所設(shè)定的任務(wù)粒度的閥值也應(yīng)該隨著線程數(shù)目成比例的增長。

4.3 內(nèi)存分配和字寬

在上文提到的測試程序中，有四個程序會創(chuàng)建并操作數(shù)量巨大的共享數(shù)組和矩陣：數(shù)字排序，矩陣相乘/分解以及松弛。其中，排序算法應(yīng)該是對數(shù)據(jù)移動操作（將內(nèi)存數(shù)據(jù)移動到CPU緩存）以及系統(tǒng)總內(nèi)存帶寬，最為敏感的。為了確定這些影響因素的性質(zhì)，我們將排序算法sort改寫為四個版本，分別對byte字節(jié)數(shù)據(jù)，short型數(shù)據(jù)，int型數(shù)據(jù)以及l(fā)ong型數(shù)據(jù)進(jìn)行排序。這些程序所操作的數(shù)據(jù)都在0 ~ 255之間，以確保這些對比測試之間的平等性。理論上，操作數(shù)據(jù)的字寬越大，內(nèi)存操作壓力也相應(yīng)越大。

測試結(jié)果顯示，內(nèi)存操作壓力的增加會導(dǎo)致加速比的降低，雖然我們無法提供明確的證據(jù)來證明這是引起這種表現(xiàn)的唯一原因。但數(shù)據(jù)的字寬的確是影響程序的性能的。比如，使用一個線程，排序字節(jié)byte數(shù)據(jù)需要耗時122.5秒，然而排序long數(shù)據(jù)則需要耗時242.5秒。

4.4 任務(wù)同步

正如3.2章節(jié)所討論的，任務(wù)竊取模型經(jīng)常會在處理任務(wù)的同步上遇到問題，如果工作線程獲取任務(wù)的時候，但相應(yīng)的隊列已經(jīng)沒有任務(wù)可供獲取，這樣就會產(chǎn)生競爭。在FJTask框架中，這種情況有時會導(dǎo)致線程強(qiáng)制睡眠。

從Jacobi程序中我們可以看到這類問題。Jacobi程序運行100步，每一步的操作，相應(yīng)矩陣點周圍的單元都會進(jìn)行刷新。程序中有一個全局的屏障分隔。為了明確這種同步操作的影響大小。我們在一個程序中每10步操作進(jìn)行一次同步。如圖中表現(xiàn)出的擴(kuò)展性的差異說明了這種并發(fā)策略的影響。也暗示著我們在這個框架后續(xù)的版本中應(yīng)該增加額外的方法以供程序員來重寫，以調(diào)整框架在不同的場景中達(dá)到最大的效率。（注意，這種圖可能對同步因素的影響略有夸大，因為10步同步的版本很可能需要管理更多的任務(wù)局部性）

4.5 任務(wù)局部性

FJTask，或者說其他的Fork/Join框架在任務(wù)分配上都是做了優(yōu)化的，盡可能多的使工作線程處理自己分解產(chǎn)生的任務(wù)。因為如果不這樣做，程序的性能會受到影響，原因有二：

• 從其他隊列竊取任務(wù)的開銷要比在自己隊列執(zhí)行pop操作的開銷大。
• 在大多數(shù)程序中，任務(wù)操作操作的是一個共享的數(shù)據(jù)單元，如果只運行自己部分的任務(wù)可以獲得更好的局部數(shù)據(jù)訪問。

如上圖所示，在大多數(shù)程序中，竊取任務(wù)的相對數(shù)據(jù)都最多維持在很低的百分比。然后其中LU和MM程序隨著線程數(shù)目的增加，會在工作負(fù)載上產(chǎn)生更大的不平衡性（相對的產(chǎn)生了更多的任務(wù)竊取）。通過調(diào)整算法我們可以降低這種影響以獲得更好的加速比。

4.6 與其他框架比較

與其他不同語言的框架相比較，不太可能會得到什么明確的或者說有意義的比較結(jié)果。但是，通過這種方法，最起碼可以知道FJTask在與其他語言（這里主要指的是C和C++）所編寫的相近框架比較所表現(xiàn)的優(yōu)勢和限制。下面這個表格展示了幾種相似框架（Cilk、Hood、Stackthreads以及Filaments）所測試的性能數(shù)據(jù)。涉及到的測試都是在4 CPU的Sun Enterprise 450服務(wù)器運行4個線程進(jìn)行的。為了避免在不同的框架或者程序上進(jìn)行重新配置，所有的測試程序運行的問題集都比上面的測試稍小些。得到的數(shù)據(jù)也是取三次測試中的最優(yōu)值，以確保編譯器或者說是運行時配置都提供了最好的性能。其中Fib程序沒有指定任務(wù)粒度的閥值，也就是說默認(rèn)的1。（這個設(shè)置在Filaments版的Fib程序中設(shè)置為1024，這樣程序會表現(xiàn)的和其它版本更為一致）。

在加速比的測試中，不同框架在不同程序上所得到的測試結(jié)果非常接近，線程數(shù)目1 ~ 4，加速比表現(xiàn)在（3.0 ~ 4.0之間）。因此下圖也就只聚焦在不同框架表現(xiàn)的不同的絕對性能上，然而因為在多線程方面，所有的框架都是非常快的，大多數(shù)的差異更多的是有代碼本身的質(zhì)量，編譯器的不同，優(yōu)化配置項或者設(shè)置參數(shù)造成的。實際應(yīng)用中，根據(jù)實際需要選擇不同的框架以彌補(bǔ)不同框架之間表現(xiàn)的巨大差異。

FJTask在處理浮點數(shù)組和矩陣的計算上性能表現(xiàn)的比較差。即使Java虛擬機(jī)性能不斷的提升，但是相比于那些C和C++語言所使用的強(qiáng)大的后端優(yōu)化器，其競爭力還是不夠的。雖然在上面的圖表中沒有顯示，但FJTask版本的所有程序都要比那些沒有進(jìn)行編譯優(yōu)化的框架還是運行的快的。以及一些非正式的測試也表明，測試所得的大多數(shù)差異都是由于數(shù)組邊界檢查，運行時義務(wù)造成的。這也是Java虛擬機(jī)以及編譯器開發(fā)者一直以來關(guān)注并持續(xù)解決的問題。

相比較，計算敏感型程序因為編碼質(zhì)量所引起的性能差異卻是很少的。

5. 結(jié)論

本論文闡述了使用純Java實現(xiàn)支持可移植的（portable）、高效率的（efficient）和可伸縮的（scalable）并行處理的可能性，并提供了便利的API讓程序員可以遵循很少幾個設(shè)計規(guī)則和模式（參考資料[7]中有提出和討論）就可以利用好框架。從本文的示例程序中觀察分析到的性能特性也同時為用戶提供了進(jìn)一步的指導(dǎo)，并提出了框架本身可以潛在改進(jìn)的地方。

盡管所展示的可伸縮性結(jié)果針對的是單個JVM，但根據(jù)經(jīng)驗這些主要的發(fā)現(xiàn)在更一般的情況下應(yīng)該仍然成立：

• 盡管分代GC（generational GC）通常與并行協(xié)作得很好，但當(dāng)垃圾生成速度很快而迫使GC很頻繁時會阻礙程序的伸縮性。在這樣的JVM上，這個底層原因看起來會導(dǎo)致為了GC導(dǎo)致停止線程的花費的時間大致與運行的線程數(shù)量成正比。因為運行的線程越多那么單位時間內(nèi)生成的垃圾也就越多，開銷的增加大致與線程數(shù)的平方。即使如此，只有在GC頻度相對高時，才會對性能有明顯的影響。當(dāng)然，這個問題需要進(jìn)一步的研究和開發(fā)并行GC算法。本文的結(jié)果也說明了，在多處理器JVM上提供優(yōu)化選項（tuning options）和適應(yīng)機(jī)制（adaptive mechanisms）以讓內(nèi)存可以按活躍CPU數(shù)目擴(kuò)展是有必要的。
• 大多數(shù)的伸縮性問題只有當(dāng)運行的程序所用的CPU多于多數(shù)設(shè)備上可用CPU時，才會顯現(xiàn)出來。FJTask（以及其它Fork/Join框架）在常見的2路、4路和8路的SMP機(jī)器上表現(xiàn)出接近理想情況加速效果。對于為stock multiprocessor設(shè)計的運行在多于16個CPU上的Fork/Join框架，本文可能是第一篇給出系統(tǒng)化報告結(jié)果的論文。在其它框架中這個結(jié)果中的模式是否仍然成立需要進(jìn)一步的測量。
• 應(yīng)用程序的特征（包括內(nèi)存局部性、任務(wù)局部性和全局同步的使用）常常比框架、JVM或是底層OS的特征對于伸縮性和絕對性能的影響更大。舉個例子，在非正式的測試中可以看到，精心避免deques上同步操作（在3.1節(jié)中討論過）對于生成任務(wù)相對少的程序（如LU）完全沒有改善。然而，把任務(wù)管理上開銷減至最小卻可以拓寬框架及其相關(guān)設(shè)計和編程技巧的適用范圍和效用。

除了對于框架做漸進(jìn)性的改良，未來可以做的包括在框架上構(gòu)建有用的應(yīng)用（而不是Demo和測試）、在生產(chǎn)環(huán)境的應(yīng)用負(fù)載下的后續(xù)評估、在不同的JVM上測量以及為搭載多處理器的集群的方便使用開發(fā)擴(kuò)展。

6. 致謝

本文的部分工作受到來自Sun實驗室的合作研究資助的支持。感謝Sun實驗室Java課題組的 Ole Agesen、Dave Detlefs、Christine Flood、Alex Garthwaite 和 Steve Heller 的建議、幫助和評論。David Holmes、Ole Agesen、Keith Randall、Kenjiro Taura 以及哪些我不知道名字的審校人員為本論文的草稿提供的有用的評論。Bill Pugh 指出了在3.1節(jié)討論到的JVM的寫后讀的局限（read?after?write limitations）。特別感謝 Dave Dice 抽出時間在30路企業(yè)機(jī)型上執(zhí)行了測試。

7. 參考文獻(xiàn)

[1] Agesen, Ole, David Detlefs, and J. Eliot B. Moss. Garbage Collection and Local Variable Type?Precision and Liveness in Java Virtual Machines. In Proceedings of 1998 ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI), 1998.
[2] Agesen, Ole, David Detlefs, Alex Garthwaite, Ross Knippel, Y.S. Ramakrishna, and Derek White. An Efficient Meta?lock for Implementing Ubiquitous Synchronization. In Proceedings of OOPSLA ’99, ACM, 1999.
[3] Arora, Nimar, Robert D. Blumofe, and C. Greg Plaxton. Thread Scheduling for Multiprogrammed Multiprocessors. In Proceedings of the Tenth Annual ACM Symposium on Parallel Algorithms and Architectures (SPAA), Puerto Vallarta, Mexico, June 28 ? July 2, 1998.
[4] Blumofe, Robert D. and Dionisios Papadopoulos. Hood: A User?Level Threads Library for Multiprogrammed Multiprocessors. Technical Report, University of Texas at Austin, 1999.
[5] Frigo, Matteo, Charles Leiserson, and Keith Randall. The Implementation of the Cilk?5 Multithreaded Language. In Proceedings of 1998 ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI), 1998.
[6] Gosling, James, Bill Joy, and Guy Steele. The Java Language Specification, Addison?Wesley, 1996.
[7] Lea, Doug. Concurrent Programming in Java, second edition, Addison?Wesley, 1999.
[8] Lowenthal, David K., Vincent W. Freeh, and Gregory R. Andrews. Efficient Fine?Grain Parallelism on Shared?Memory Machines. Concurrency?Practice and Experience, 10,3:157?173, 1998.
[9] Simpson, David, and F. Warren Burton. Space efficient execution of deterministic parallel programs. IEEE Transactions on Software Engineering, December, 1999.
[10] Taura, Kenjiro, Kunio Tabata, and Akinori Yonezawa. “Stackthreads/MP: Integrating Futures into Calling Standards.” In Proceedings of ACM SIGPLAN Symposium on Principles & Practice of Parallel Programming (PPoPP), 1999.

總結(jié)

以上是生活随笔為你收集整理的Java Fork/Join 框架的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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