lambda表達(dá)式以及并行流。官方承諾你寫出來的代碼更運(yùn)行得更快。流會自動(dòng)通過Fork/Join池并行地執(zhí)行。我聽過一些關(guān)于Java 8的主題的演講，不過在這個(gè)非常關(guān)鍵的點(diǎn)上它們都說的有點(diǎn)問題。我計(jì)劃在后續(xù)的文章中對并行流進(jìn)行下深入的講解，在這之前我先花點(diǎn)時(shí)間仔細(xì)地分析下它。關(guān)于這個(gè)問題，我只想問你們一個(gè)非常簡單的問題，不過也是一個(gè)非常重要的問題，因?yàn)樗呛芏鄦栴}的關(guān)鍵所在。這個(gè)問題是：

這些并行操作的線程都是從哪來的？

在Java 8里，我們有一個(gè)通用的Fork/Join池，我們可以通過ForkJoinPool.commonPool()來訪問它。并行流，并行排序，CompletableFuture等都會用到它。當(dāng)你構(gòu)造一個(gè)Fork/Join池的時(shí)候，通常你都沒有指定最大線程數(shù)。你只是指定了一個(gè)期望的并發(fā)數(shù)，也就是說你希望在運(yùn)行時(shí)的同一時(shí)間有多少活躍的線程。當(dāng)線程被阻塞在一個(gè)phaser的時(shí)候，會創(chuàng)建另一個(gè)線程來保證池里有足夠的活躍線程。這個(gè)phaser就是觸發(fā)這個(gè)行為的同步器。Fork/Join池最大的線程數(shù)是32767，但在遠(yuǎn)沒達(dá)到這個(gè)數(shù)量時(shí)，在大多數(shù)操作系統(tǒng)上就會拋出OutOfMemoryError異常了。在這段示例代碼中，我會不斷創(chuàng)建新的RecursiveAction真到達(dá)到第一個(gè)階段（也就是到達(dá)了200個(gè)線程）。如果我們增加到一個(gè)更大的數(shù)字，比如說到100000，這段代碼就會失敗了。

import java.util.concurrent.*;

public class PhaserForkJoin {
 public static void main(String... args) {
  ForkJoinPool common = ForkJoinPool.commonPool();
  Phaser phaser = new Phaser(200);
  common.invoke(new PhaserWaiter(phaser));
 }

 private static class PhaserWaiter extends RecursiveAction {
  private final Phaser phaser;

  private PhaserWaiter(Phaser phaser) {
   this.phaser = phaser;
   System.out.println(ForkJoinPool.commonPool().getPoolSize());
  }

  protected void compute() {
   if (phaser.getPhase() > 0) return; // we've passed first phase
   PhaserWaiter p1 = new PhaserWaiter(phaser);
   p1.fork();
   phaser.arriveAndAwaitAdvance();
   p1.join();
  }
 }
}

Fork/Join池沒有一個(gè)最大線程數(shù)，只有一個(gè)期望并發(fā)數(shù)，這是指我們希望同時(shí)有多少個(gè)活躍線程。

通用池是很有用的，因?yàn)樗馕吨煌愋偷淖鳂I(yè)可以共享同一個(gè)池，而不用超出代碼所運(yùn)行的機(jī)器上期望并發(fā)數(shù)。當(dāng)然了，如果一個(gè)線程由于非Phaser的其它原因阻塞了，那可能這個(gè)通用池的表現(xiàn)就和預(yù)期的不太一樣了。

什么是通用FJ池的默認(rèn)的期望并發(fā)數(shù)？

通常的FJ池的期望并發(fā)數(shù)的默認(rèn)值是Runtime.getRuntime().availableProcessors() -1。如果你在一個(gè)雙核的機(jī)器上通過Arrays.parallelSort()來運(yùn)行并行排序的話，默認(rèn)使用的是普通的Arrays.sort()方法。盡管Oracle的官方文檔可能許諾你可以獲得性能提升，但是你在一個(gè)雙核的機(jī)器上可能完全看不著任何提升。

然而，更大的問題在于Runtime.getRuntime().availableProcessors()也并非都能返回你所期望的數(shù)值。比如說，在我的雙核1-2-1機(jī)器上，它返回的是2，這是對的。不過在我的1-4-2機(jī)器 上，也就是一個(gè)CPU插槽，4核，每個(gè)核2個(gè)超線程，這樣的話會返回8。不過我其實(shí)只有4個(gè)核，如果代碼的瓶頸是在CPU這塊的話，我會有7個(gè)線程在同時(shí) 競爭CPU周期，而不是更合理的4個(gè)線程。如果我的瓶頸是在內(nèi)存這的話，那這個(gè)測試我可以獲得7倍的性能提升。

不過這還沒完！Java Champions上的一個(gè)哥們發(fā)現(xiàn)了一種情況，他有一臺16-4-2的機(jī)器 （也就是16個(gè)CPU插槽，每個(gè)CPU4個(gè)核，每核兩個(gè)超線程，返回的值居然是16！從我的i7 Macbook pro上的結(jié)果來看，我覺得應(yīng)該返回的是16*4*2=128。在這臺機(jī)器上運(yùn)行Java 8的話，它只會將通用的FJ池的并發(fā)數(shù)設(shè)置成15。正如 Brian Goetz所指出的，“虛擬機(jī)其實(shí)不清楚什么是處理器，它只是去請求操作系統(tǒng)返回一個(gè)值。同樣的，操作系統(tǒng)也不知道怎么回事，它是去問的硬件設(shè)備。硬件會告訴它一個(gè)值，通常來說是硬件線程數(shù)。操作系統(tǒng)相信硬件說的，而虛擬機(jī)又相信操作系統(tǒng)說的?！?/p>

所幸的是還有一個(gè)解決方案。啟動(dòng)的時(shí)候，你可以通過系統(tǒng)屬性 java.util.concurrent.ForkJoinPool.common.parallelism來設(shè)置通用池的并發(fā)數(shù)。也就是說，我們可以通過-Djava.util.concurrent.ForkJoinPool.common.parallelism=128來啟動(dòng)這段程序，現(xiàn)在你可以看到它的并發(fā)數(shù)是128了：

import java.util.concurrent.*;

public class ForkJoinPoolCommon {
 public static void main(String... args) {
  System.out.println(ForkJoinPool.commonPool());
 }
}

還有兩個(gè)控制通用池的額外的系統(tǒng)屬性。如果你希望處理未捕獲異常的話，你可以通過java.util.concurrent.ForkJoinPool.common.exceptionHandler來指定一個(gè)處理類。如果你希望有自己的線程工廠的話，可以通過 java.util.concurrent.ForkJoinPool.common.threadFactory來配置。默認(rèn)的Fork/Join池的工廠生成的是守護(hù)線程，可能你的應(yīng)用里面不希望使用它。不過如果你這么做的話請小心——這樣你就無法關(guān)閉這個(gè)通用池了。

到此這篇關(guān)于詳解Java8與Runtime.getRuntime().availableProcessors()的文章就介紹到這了,更多相關(guān)Java8與Runtime.getRuntime().availableProcessors()內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！