淺談JDK8并行流及串行流的區(qū)別

小編這次要給大家分享的是淺談JDK8并行流及串行流的區(qū)別，文章內(nèi)容豐富，感興趣的小伙伴可以來了解一下，希望大家閱讀完這篇文章之后能夠有所收獲。

由于處理器核心的增長及較低的硬件成本允許低成本的集群系統(tǒng)，致使如今并行編程無處不在，并行編程似乎是下一個大事件。

Java 8 針對這一事實(shí)提供了新的 stream API 及簡化了創(chuàng)建并行集合和數(shù)組的代碼。讓我們看一下它是怎么工作的。

假設(shè) myList 是 List<Integer> 類型的，其中包含 500,000 個Integer值。在Java 8 之前的時(shí)代中，對這些整數(shù)求和的方法是使用 for 循環(huán)完成的。

for( int i : myList){
 result += i;
}

從 Java 8 開始，我們就可以使用stream完成同樣的循環(huán)：

myList.stream().sum();

將此代碼改為并行處理非常簡單，僅需要使用 parallelStream() 代替 stream() 或 parallel()搭配stream使用：

mylist.stream().parallelStream().sum();

這樣就可以成功的變?yōu)椴⑿谐绦?，所以將一個計(jì)算擴(kuò)展到線程和CPU內(nèi)核上并可用很容易就可以實(shí)現(xiàn)。但是我們都知道，多線程和并行處理的開銷很大，所以重點(diǎn)是什么時(shí)候使用并行流，什么時(shí)候使用串行流才能獲得更好的性能。

首先，讓我們看看在幕后發(fā)生的事情。parallel stream 使用的是 Fork/Join 框架進(jìn)行處理的，這意味著 stream 流的源會被拆分并移交給 fork/join 池中執(zhí)行。

首先，我們找到了要考慮的第一點(diǎn)：并非所有的stream的源會像其它的stream的源一樣可拆分。例如：ArrayList的內(nèi)部實(shí)現(xiàn)是數(shù)組，由于可以通過計(jì)算出中間元素的索引來拆分，所以拆分這樣的源會非常容易；假如使用LinkedList，則拆分?jǐn)?shù)據(jù)會復(fù)雜的多：該實(shí)現(xiàn)必須遍歷第一個條目中的所有元素，以便找到可以拆分的元素，所以LinkedList是并行流中性能差的例子。

這是我們可以保留的關(guān)于并行流性能的第一個事實(shí)：

S ： 源集合必須可以有效拆分

拆分集合、管理 Fork/Join 任務(wù)、對象創(chuàng)建及 GC 也是算法上的開銷，當(dāng)且僅當(dāng)在CPU核心上可簡單完成或者集合足夠大時(shí)，才值得這樣做。

一個錯誤的例子：求5個整數(shù)的最大值。

Intstream.rangeClosed(1,5).reduce(Math::max).getAsInt();

系統(tǒng)為fork/join準(zhǔn)備和處理數(shù)據(jù)的開銷非常大，以至于串行流在此場景中要快得多。Math.max 方法在這里的CPU開銷并不是很高，而且數(shù)據(jù)元素很少。

舉個例子，在編寫象棋游戲的時(shí)候，對每個棋子移動的評估。每一個評估都可以并行執(zhí)行，并且我們有大量可能的下一步移動。這種情形非常適合并行處理。

這是我們可以保留的關(guān)于并行流性能的第二個事實(shí)：

N * Q： 因子”元素?cái)?shù)量” * “ 每個元素的運(yùn)行成本” 應(yīng)該很大

但這同樣意味著當(dāng)每個元素的操作成本更高的時(shí)候，集合可以更小。或當(dāng)每個元素的操作不那么占用大量CPU時(shí)，我們需要一個包含許多元素的非常大的集合，以便并行流的使用的到回報(bào)。

這直接取決于我們可以保留的第三個事實(shí)

C ：CPU核心數(shù)量 - 越多越好 > 必須有1個

由于管理開銷，在單核計(jì)算機(jī)上的并行流始終比串行流的性能差。

越多越好：實(shí)際上，這句話并不是在所有情況下都正確。例如：集合太小且CPU核心啟動時(shí)處于節(jié)能模式進(jìn)而導(dǎo)致CPU無事可做。

能否使用并行流，對每個元素的功能（function）也有要求，這涉及到并行流能否按照預(yù)期工作：

要求該功能（function）：

• 獨(dú)立：每個元素的計(jì)算都不依賴或影響任何其他元素的計(jì)算
• 無干擾：功能（function）執(zhí)行的時(shí)候不會修改基礎(chǔ)的數(shù)據(jù)源
• 無狀態(tài)

例：并行流中使用有狀態(tài)lamdba方法的實(shí)例，來源自 Java JDK API

Set seen = Collection.synchronizedSet(new HashSet());
stream.parallel().map( e -> {
    if(seen.add(e))
      return 0;
    else
      return e;
  })...

于是，這是我們可以保留的第四個事實(shí)：

F ：每個元素必須獨(dú)立

總結(jié)：

還有其他情況不應(yīng)該并行化流嗎？有。

我們要始終考慮每一個元素的功能（function）在做什么及它是否適合運(yùn)行在并行代碼中。當(dāng)方法是調(diào)用一些同步方法，并行流可能會在同步方法上等待，進(jìn)而導(dǎo)致并行流的性能并沒有想象中高。

同樣的，在調(diào)用BI/O操作時(shí)，由于數(shù)據(jù)是按照順序讀取的，以I/O源作為流，也會發(fā)生同樣的問題。

看完這篇關(guān)于淺談JDK8并行流及串行流的區(qū)別的文章，如果覺得文章內(nèi)容寫得不錯的話，可以把它分享出去給更多人看到。