轉載自?http://www.importnew.com/27334.html

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

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

Java 7提供了ForkJoinPool，支持了Java 8提供的Stream（Reactive Stream是RP的一個核心組件）。
另外Java 8還提供了Lamda（有效地表達和使用RP需要FP的語言構件和理念）。
有了前面的這些穩健但不失時機的準備，在Java 9中提供了面向RP的Flow API，為Java圈子提供了官方的RP API，標志著RP由集市式的自由探索階段 向 教堂式的統一使用的轉變。

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

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

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

0. 摘要

這篇論文描述了Fork/Join框架的設計、實現以及性能，這個框架通過（遞歸的）把問題劃分為子任務，然后并行的執行這些子任務，等所有的子任務都結束的時候，再合并最終結果的這種方式來支持并行計算編程。總體的設計參考了為Cilk設計的work-stealing框架。就設計層面來說主要是圍繞如何高效的去構建和管理任務隊列以及工作線程來展開的。性能測試的數據顯示良好的并行計算程序將會提升大部分應用，同時也暗示了一些潛在的可以提升的空間。

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

1. 簡介

Fork/Join并行方式是獲取良好的并行計算性能的一種最簡單同時也是最有效的設計技術。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子任務。join操作會一直等待直到所有的子任務都結束。Fork/Join算法，如同其他分治算法一樣，總是會遞歸的、反復的劃分子任務，直到這些子任務可以用足夠簡單的、短小的順序方法來執行。

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

2. 設計

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

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

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

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

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

作為一個給程序員演示這個框架如何運行的標準實例，這是一個計算法斐波那契函數的類。

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節中所提到的平臺上的運行速度至少比每個任務都在Thread類中運行快30倍。在保持性能的同時這個程序仍然維持著Java多線程程序的可移植性。對程序員來說通常有兩個參數值的他們關注：

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

2.1 work?stealing

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

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

使用后進先出 —— LIFO用來處理每個工作線程的自己任務，但是使用先進先出 —— FIFO規則用于獲取別的任務，這是一種被廣泛使用的進行遞歸Fork/Join設計的一種調優手段。引用[5]討論了詳細討論了里面的細節。

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

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

3. 實現

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

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

3.1 雙端隊列

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

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

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

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

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

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

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

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

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

和take預遞減到base時：

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

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

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

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

3.2 搶斷和閑置

在搶斷式工作框架中，工作線程對于他們所運行的程序對同步的要求一無所知。他們只是構建、發布、彈出、獲取、管理狀態和執行任務。這種簡單的方案使得當所有的線程都擁有很多任務需要去執行的時候，它的效率很高。然而這種方式是有代價的，當沒有足夠的工作的時候它將依賴于試探法。也就是說，在啟動一個主任務，直到它結束，在有些Fork/Join算法中都使用了全面停止的同步指針。

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

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

4. 性能

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

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

程序描述

Fib（菲波那契數列）	如第2節所描述的Fibonnaci程序，其中參數值為47閥值為13
Integrate（求積分）	使用遞歸高斯求積對公式??求-47到48的積分，i?為1到5之間的偶數
Micro（求微分）	對一種棋盤游戲尋找最好的移動策略，每次計算出后面四次移動
Sort（排序）	使用合并/快速排序算法對1億數字進行排序（基于Cilk算法）
MM（矩陣相乘）	2048 X 2048的double類型的矩陣進行相乘
LU（矩陣分解）	4096 X 4096的double類型的矩陣進行分解
Jacobi（雅克比迭代法）	對一個4096 X 4096的double矩陣使用迭代方法進行矩陣松弛，迭代次數上限為100

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

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

4.1 加速效果

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

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

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

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

4.2 垃圾回收

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

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

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

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

4.3 內存分配和字寬

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

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

4.4 任務同步

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

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

4.5 任務局部性

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

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

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

4.6 與其他框架比較

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

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

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

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

5. 結論

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

盡管所展示的可伸縮性結果針對的是單個JVM，但根據經驗這些主要的發現在更一般的情況下應該仍然成立：

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

除了對于框架做漸進性的改良，未來可以做的包括在框架上構建有用的應用（而不是Demo和測試）、在生產環境的應用負載下的后續評估、在不同的JVM上測量以及為搭載多處理器的集群的方便使用開發擴展。

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節討論到的JVM的寫后讀的局限（read?after?write limitations）。特別感謝 Dave Dice 抽出時間在30路企業機型上執行了測試。

7. 參考文獻

[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.

總結

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

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