2019獨角獸企業重金招聘Python工程師標準>>>

Java 8 已經發布一段時間了，許多開發者已經開始使用 Java 8。本文也將討論最新發布在 JDK 中的并發功能更新。事實上，JDK 中已經有多處java.util.concurrent 改動，但本文重點將是 Fork-Join 框架的改進。我們將討論一點 Fork-Join，然后實現一個簡單的基準測試以比較 FJ 在 Java 7 和Java 8 中的性能。

##你可能對Fork/Join在意的地方

ForkJoin 是一個通常用于并行計算遞歸任務的框架。它最早被引入Java 7 中，從那時起它就能很好地完成目標任務。原因在于，許多大型任務本質上都可以遞歸表示。

以最有名的 MapReduce 編程為例：對一篇文章中不同詞的出現次數進行統計。很顯然，可以將文檔分為很多部分，逐項地記錄字數，最后再合并成結果。誠然，ForkJoin其實是 MapReduce 基本法則的一種實現，區別在于，所有的 worker 都是同一個虛擬機中的線程，而不是一組機器。

ForkJoin 框架的核心部分是 ForkJoinPool ，它是一個 ExecutorService， 能夠接收異步任務，返回Future對象，因此可用于跟蹤執行中的計算狀態。

使 ForkJoinPool 不同于其他 ExecutorServices 的是，在當下并不執行任務的工作線程會檢查其伙伴的工作狀態，并向他們借取任務。這種技術稱為 work-stealing 。那么，work-stealing 有什么妙用呢？

work-stealing 是一種分散式的工作量管理方法，無需將工作單元分配給所有可用的工作線程，而是每個線程自己管理其任務隊列。關鍵在于高效地管理這些隊列。

關于讓每個工作進程處理自己的隊列，有兩個主要問題：

• 外部提交的任務去哪里了?
• 我們怎樣組織 work-stealing 以有效訪問隊列

本質上來說，在執行大型任務時，外部提交任務和由工作線程創建的任務之間區別不大。他們都有類似的執行要求并提供結果。然而，運作方式是不同的。最主要的區別在于由工作進程創建的任務可以被竊取。這意味著即便被放進了一個工作進程的任務隊列中，他們仍可能被其他工作進程執行。

ForkJoin 框架處理它的方法很簡單，每個工作線程都有2個任務隊列，一個用于外部任務，另一個用于實現竊取工作進程的運作。當外部提交任務時，會將任務添加至隨機的工作隊列中。當一個任務被分為更小的任務時，工作線程將他們添加到自己的任務隊列中，并希望其他工作線程來幫忙。

竊取任務的想法基于以下事實：工作線程在它任務隊列末尾添加任務。在正常的執行過程中，每個工作線程試著去從任務隊列的隊首拿任務，當其個人隊列的任務為空時，這一操作就會失敗，轉而竊取別的工作線程的任務隊列末尾的任務。這有效避免了多數任務隊列的互鎖問題，提高了性能。

另一個使 ForkJoin 池工作更快的訣竅是當一個工作線程竊取任務時，它留下了它在哪里取得任務的線索，這樣原始的工作線程可以找到它并且幫助該工作線程，因此父任務的的工作進展會更快。

總而言之，這是一套極其復雜的系統，需要大量的背景知識使其順利運行。并且，系統的屬性和性能與具體實現的方式關系很大。因此筆者懷疑，若不進行重大的重構，系統會徹底改變。

Java 7 中 ForkJoin 有什么問題？

在 Java 7 中引入 ForkJoin 框架之后，它運行良好。然而它并沒有停止進步。在 Java 8 的并發性更新中， ForkJoin 得到改善。從這次的 Java 增強方案中，我們可以了解改善的內容。

增加了 ForkJoinPools 的功能并提高其性能，使其應用在用戶希望的日益廣泛的應用中，且效率更高。新特性包括對最適于 IO-bound 使用的 completion-based 設計的支持等。

另一個消息來源當然是與改進作者的對話，例如，Doug Lea 早前曾提到的更新有：

當大量的用戶提交大量任務時，吞吐量能大幅度提高。其原理是將外部提交者與工作線程相似地對待——均使用隨機任務隊列和竊取任務。當所有任務都為異步，且被提交至 pool 而不是 forked 時，能極大地提高吞吐量。

然而找出究竟什么被改變了、哪些場景被影響了并不簡單。因此，讓我們換一種方式解決。筆者會創建一個基準測試程序以模仿簡單的 ForkJoin 計算，并測量 ForkJoin 處理任務與單個線程依次完成任務各自所需時間，希望這種方法能幫我們找出改善的具體內容。

##Java 8 和 Java 7 性能的比較

筆者創建了一個基準測試程序以探索 Java 7 和 Java 8 之間的區別是否真的明顯。如果你想查看源碼，或者親自嘗試，這里是其 Github repo 。

由于Oracle工程師的努力，OpenJDK現在已經包含 Java Microbenchmark Harness （JMH）項目，該項目專用于創建基準測試程序，且不容易出現常見的微基準測試問題與錯誤。

JMH 還附帶了 Maven 原型項目。因此，將一切設置好其實很簡單。

org.openjdk.jmhmh-core0.4.1

在寫本文時，JMH core 的最新版本是 0.4.1 ，包括了 @Param 注釋，可用一系列的參數化輸入運行基準測試程序。這減輕了手動重復執行相同基準測試的痛苦，并簡化了獲取結果的流程。

現在，每個基準測試迭代會獲得自己的 ForkJoinPool 實例，這也減少了常用 ForkJoinPool 實例化在 Java 8 與其之前版本中的區別。

@BenchmarkMode(Mode.Throughput) @OutputTimeUnit(TimeUnit.MILLISECONDS) @Warmup(iterations = 5, time = 3, timeUnit = TimeUnit.SECONDS) @Measurement(iterations = 20, time = 3, timeUnit = TimeUnit.SECONDS) @Fork(1) @State(Scope.Benchmark) public class FJPBenchmark {@Param({ "200", "400", "800", "1600"})public int N;public List<recursivetask> tasks;public ForkJoinPool pool = new ForkJoinPool();@Setuppublic void init() {Random r = new Random();r.setSeed(0x32106234567L);tasks = new ArrayList<recursivetask>(N * 3);for (int i = 0; i < N; i++) {tasks.add(new Sin(r.nextDouble()));tasks.add(new Cos(r.nextDouble()));tasks.add(new Tan(r.nextDouble()));}}@GenerateMicroBenchmarkpublic double forkJoinTasks() {for (RecursiveTask task : tasks) {pool.submit(task);}double sum = 0;Collections.reverse(tasks);for (RecursiveTask task : tasks) {sum += task.join();}return sum;}@GenerateMicroBenchmarkpublic double computeDirectly() {double sum = 0;for (RecursiveTask task : tasks) {sum += ((DummyComputableThing) task).dummyCompute();}return sum;} }

Sin 、Cos 和 Tan 是 RecursiveTask 的實例，實際上 Sin 和 Cos 并不遞歸，但會分別計算 Math.sin(input) 和 Math.cos(input) 的值 。Tan 的任務實際上會遞歸為一組 Sin 和 Cos ，并返回兩者的除法結果。

JMH 處理項目的代碼并從標有 @GenerateMicroBenchmark 注釋的方法處生成基準測試程序。你在該類上方看到的其他注釋指定了基準測試的選項：迭代次數，計入最終結果的迭代次數，是否 fork 另一個 JVM 進程用于基準測試以及測量哪些值。測量值可以是代碼的吞吐量，或這些方法在一段時間內的執行次數。

@Param 指定運行基準測試程序時幾個輸入的大小。總而言之，JMH非常簡單，創建基準測試程序不需要手動處理迭代、定時或整理結果。

用 Java 7 和 8 運行該基準測試得到以下結果。筆者分別使用的是1.7.0_40 and 1.8.0.版本。

shelajev@shrimp ~/repo/blogposts/fork-join-blocking-perf ? java -version java version "1.7.0_40" Java(TM) SE Runtime Environment (build 1.7.0_40-b43) Java HotSpot(TM) 64-Bit Server VM (build 24.0-b56, mixed mode)Benchmark (N) Mode Samples Mean Mean error Units o.s.FJPB.computeDirectly 200 thrpt 20 27.890 0.306 ops/ms o.s.FJPB.computeDirectly 400 thrpt 20 14.046 0.072 ops/ms o.s.FJPB.computeDirectly 800 thrpt 20 6.982 0.043 ops/ms o.s.FJPB.computeDirectly 1600 thrpt 20 3.481 0.122 ops/ms o.s.FJPB.forkJoinTasks 200 thrpt 20 11.530 0.121 ops/ms o.s.FJPB.forkJoinTasks 400 thrpt 20 5.936 0.126 ops/ms o.s.FJPB.forkJoinTasks 800 thrpt 20 2.931 0.027 ops/ms o.s.FJPB.forkJoinTasks 1600 thrpt 20 1.466 0.012 ops/msshelajev@shrimp ~/repo/blogposts/fork-join-blocking-perf ? java -version java version "1.8.0" Java(TM) SE Runtime Environment (build 1.8.0-b132) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, mixed mode)Benchmark (N) Mode Samples Mean Mean error Units o.s.FJPB.computeDirectly 200 thrpt 20 27.680 2.050 ops/ms o.s.FJPB.computeDirectly 400 thrpt 20 13.690 0.994 ops/ms o.s.FJPB.computeDirectly 800 thrpt 20 6.783 0.548 ops/ms o.s.FJPB.computeDirectly 1600 thrpt 20 3.364 0.304 ops/ms o.s.FJPB.forkJoinTasks 200 thrpt 20 15.868 0.291 ops/ms o.s.FJPB.forkJoinTasks 400 thrpt 20 8.060 0.222 ops/ms o.s.FJPB.forkJoinTasks 800 thrpt 20 4.006 0.024 ops/ms o.s.FJPB.forkJoinTasks 1600 thrpt 20 1.968 0.043 ops/ms

為了便于查看結果，下面以圖表形式進行展示。

我們可以看到 JDK 7 與 8 間的基線結果（直接用同一線程運行程序的吞吐量）差異并不大。然而，若加入管理遞歸任務的時間，使用 ForkJoin 來執行，則 Java 8 的速度更快。這個簡單的基準測試表明，在最新版的 Java 中，管理 ForkJoin 任務的效率有了 35% 左右的性能提高。

基線和 FJ 計算之間的結果差異是因為我們刻意創建的遞歸任務非常單薄。該任務實質上只是調用一個優化后的數學類。因此，直接進行數學運算會快得多。一個更強壯的任務必將改變這一情況，但是它們會減輕 ForkJoin 管理的開銷，而這是我們起初就想測量的目標。不過，一般而言，執行遞歸任務比多次執行同個方法調用要高效得多。

同時，Java 7 和 Java 8 的基線測試結果也有略微的不同。這個差異是可以忽視的，但很可能不是因為 Java 7 和 8 中數學類的實現差異造成的。而是一個測量假象，JMH 努力抵消卻還是無法避免。

免責聲明：當然，這些結果是模擬所得的，你應該持保留態度。然而，除了討論 Java 性能，筆者也想展示 JMH 創建基準測試程序是如何簡單，且能避免一些常見基準測試問題，比如沒有提前預熱 JVM 。如果基準測試本身存在缺陷，熱身也無濟于事，但是肯定還是有所裨益。因此，如果你看到以上代碼中的邏輯缺陷，請一定告訴筆者。

##總結： 首先，ForkJoinPool, ForkJoinPool.WorkQueue 和ForkJoinTask 類的源碼并不容易閱讀，它包含許非安全原理，因此你可能沒法在15分鐘完全理解ForkJoin 框架。

然而，這些類的文檔豐富，并且包含許多內部注釋。它也可能學習挖掘JDK最有趣的地方。

另一個相關的發現是 ForkJoinPool 在 Java8 中的性能更好，至少在一些用例中是這樣的。雖然筆者不能精確地描述這背后的原因，但如果我在代碼中用到 ForkJoin ，我一定會升級 Java 版本。

原文地址：http://zeroturnaround.com/rebellabs/is-java-8-the-fastest-jvm-ever-performance-benchmarking-of-fork-join/ 本文作者：Oleg Shelajev 系 OneAPM 工程師編譯整理。

OneAPM 為您提供端到端的 Java 應用性能解決方案，我們支持所有常見的 Java 框架及應用服務器，助您快速發現系統瓶頸，定位異常根本原因。分鐘級部署，即刻體驗，Java 監控從來沒有如此簡單。想技術文章，請訪問 OneAPM 官方技術博客。 本文轉自 OneAPM 官方博客

轉載于:https://my.oschina.net/oneapmofficial/blog/550378

總結

以上是生活随笔為你收集整理的Java 8 的 JVM 有多快？Fork-Join 性能基准测试的全部內容，希望文章能夠幫你解決所遇到的問題。

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