正如電影星球大戰那樣，Java 8的並行流也是毀譽參半。並行流(Parallel Stream)的語法糖就像預告片裏的新型光劍一樣令人興奮不已。現在Java中實現並發編程存在多種方式，我們希望了解這麽做所帶來的性能提升及風險是什麽。從經過260多次測試之後拿到的數據來看，還是增加了不少新的見解的，這裏我們想和大家分享一下。

ExecutorService vs. Fork/Join框架 vs. 並行流

在很久很久以前，在一個遙遠的星球上。。好吧，其實我只是想說，在10年前，Java的並發還只能通過第三方庫來實現。然後Java 5到來了，並引入了java.util.concurrent包，上面帶有深深的Doug Lea的烙印。ExecutorService為我們提供了一種簡單的操作線程池的方式。當然了，java.util.concurrent包也在不斷完善，Java 7中還引入了基於ExecutorService線程池實現的Fork/Join框架。對很多開發人員來說，Fork/Join框架仍然顯得非常神秘，因此Java 8的stream提供了一種更為方便地使用它的方法。我們來看下這幾種方式有什麽不同之處。

我們來通過兩個任務來進行測試，一個是CPU密集型的，一個是IO密集型的，同樣的功能，分別在4種場景下進行測試。不同實現中線程的數量也是一個非常重要的因素，因此這個也是我們測試的目標之一。測試機器共有8個核，因此我們分別使用4，8，16，32個線程來進行測試。對每個任務而言，我們還會測試下單線程的版本，不過這個在圖中並沒有標出來，因為它的時間要長得多。如果想了解這些測試用例是如何運行的，你可以看一下最後的基礎庫一節。我們開始吧。

給一段580萬行6GB大小的文本建立索引

在本次測試中我們生成了一個超大的文本文件，並通過相同的方法來建立索引。我們來看下結果如何：

單線程執行時間：176，267毫秒，大約3分鐘。 註意，上圖是從20000毫秒開始的。

1. 線程過少會浪費CPU，而過多則會增加負載

從圖中第一個容易註意到的就是柱狀圖的形狀——光從這4個數據就能大概了解到各個實現的表現是怎樣的了。8個線程到16個線程這裏有所傾斜，這是因為某些線程阻塞在了文件IO這裏，因此增加線程能更好地使用CPU資源。而當加到32個線程時，由於增加了額外的開銷，性能又開始會變差。

2. 並行流表現最佳。與直接使用Fork/Join相比要快1秒左右

並行流所提供的可不止是語法糖（這裏指的並不是lambda表達式）,而且它的性能也比Fork/Join框架以及ExecutorService要更好。索引完6GB大小的文件只需要24.33秒。請相信Java，它的性能也能做到很好。

3. 但是。。並行流的表現也是最糟糕的：唯獨它是超過了30秒的

並行流為什麽會影響性能，這裏也給你上了一課。這在本來就運行著多線程應用的機器上是有可能的。由於可用的線程本身就很少了，直接使用Fork/Join框架要比使用並行流更好一些——兩者的結果相差5秒，大約是18%的性能損耗。

4. 如果涉及到IO操作的話，不要使用默認的線程池大小

測試中使用默認線程池大小（默認值是機器的CPU核數，在這裏是8）的並行流，跟使用16個線程相比要慢上2秒。也就是說使用默認的池大小則要慢了7%。這是由於阻塞的IO線程導致的。由於有很多線程處於等待狀態，因此引入更多的線程能夠更好地利用CPU資源，當其它線程在等待調度時不至於讓它們閑著。

如果改變並行流的默認的Fork/Join池的大小？你可以通過一個JVM參數來修改公用的Fork/Join線程池的大小：

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

（默認情況下，所有的Fork/Join任務都會共用同一個線程池，線程的數量等於CPU的核數。好處就是當線程空閑下來時可以收來處理其它任務。）

或者，你還可以用下這個小技巧，用一個自定義的Fork/Join池來運行並行流。它會覆蓋掉默認的公用的Fork/Join池並讓你能夠使用自己配置好的線程池。手段有點卑劣。測試中我們使用的是公用的線程池。

5. 單線程的性能跟最快的結果相比要慢7.25倍

並發能夠提升7.25倍的性能，考慮到機器是8核的，也就是說接近是8倍的提升！還差的那點應該是消耗在線程的開銷上了。不僅如此，即便是測試中表現最差的並行版本，也就是4個線程的並行流實現（30.23秒），也比單線程的版本（176.27秒）要快5.8倍。

如果不考慮IO的話呢？比如判斷某個數是否是素數

對這次測試而言，我們將去除掉IO的部分，來測試下判斷一個大整數是否是素數要花多長時間。這個數有多大？19位，1,530,692,068,127,007,263，換句話說，一百五十三萬零六百九十二兆零六百八十一億兩千萬七千二百六十三。好吧，讓我透透氣先。我們也沒有做任何的優化，而是直接運算到它的平方根，為此我們還檢查了所有的偶數，盡管這個大數並不能被2整除，這只是為了讓運算的時間更久一些。先劇透一下：這的確是一個素數。每個實現運算的次數也都是一樣的。

下面是測試的結果：

單線程執行時間：118，127毫秒，大約2分鐘 註意，上圖是從20000毫秒開始的

1. 8個線程與16個線程相差不大

和IO測試中不同，這裏並沒有IO調用，因此8個線程和16個線程的差別並不大，Fork/Join的版本例外。由於它的反常表現，我們還多運行了好幾組測試以確保得到的結果是正確的，但事實表明，結果仍是一樣。希望你能在下方的評論一欄說一下你對這個的看法。

2. 不同實現的最好結果都很接近

我們看到，不同的實現版本最快的結果都是一樣的，大約是28秒左右。不管實現的方法如何，結果都大同小異。但這並不意味著使用哪種方法都一樣。請看下面這點。

3. 並行流的線程處理開銷要優於其它實現

這點非常有意思。在本次測試中，我們發現，並行流的16個線程的再次勝出。不止如此，在這次測試中，不管線程數是多少，並行流的表現都是最好的。

4. 單線程的版本比最快的結果要慢4.2倍

除此之外，在運行計算密集型任務時，並行版本的優勢要比帶有IO的測試要減少了2倍。由於這是個CPU密集型的測試，這個結果倒也說得過去，不像前面那個測試中那樣，減少CPU的等待IO的時間能獲得額外的收益。

結論

之前我也建議過大家讀一下源碼，了解下何時應該使用並行流，並且在Java中進行並發編程時，不要武斷地下結論。最好的檢驗方式就是在演示環境中多跑跑類似的測試用例。需要特別註意的因素包括你所運行的硬件環境 （以及測試的硬件環境），還有應用程序的總線程數。包括公用Fork/Join的線程池以及團隊中其它開發人員所寫的代碼中包含的線程。在你編寫自己的並發邏輯前，最好先檢查下上述這些情況，對你的應用程序有一個整體的了解。

基礎庫

我們是在EC2的c3.2xlarge實例上運行的本次測試，它有8個vCPU核以及15GB的內存。vCPU是因為這裏用到了超線程技術，因此實際上只有4個物理核，但每個核模擬成了兩個。對操作系統的調度器而言，認為我們一共有8個核。為了盡可能的公平，每個實現都運行了10遍，並選擇了第2次到第9次的平均運行時間。也就是一共運行了260次！處理時長也非常重要。我們所選擇的任務的運行時間都會超過20秒，因此時間差異能很容易看出來，而不太受外部因素的影響。

喜歡小編輕輕點個關註吧！

Java 中不同的並行實現的性能比較