關於Java8 Stream 的使用時機 | 程式設計

你跑的job要夠長!! 如果跑的東西都是瞬殺，那就直接用sequential跑就好了。
可以Split。可能input本身就可以split那最好，如果你中間的某一段開始一分多，例如collectors.groupingBy，那就可以讓後續的aggregation平行做。
問題本身適不適合平行。如果你的filter, mapper會有side effect，那就不能平行。reducer有沒有交換律結合律的特性，沒有也不適合平行。
輸出需不需要符合原有順序。如果你只是想要stream.map().foreach()。那是不是還想要某個順序執行。

以上幾點都非常重要，很多時候你的東西在沒有parallel是對的，但是丟到平行就錯了。當然如果以上都符合，那用parallel的好處就是善用你的每個CPU Core。看到CPU榨乾才會有滿滿的效能啊!!

另外不一定說要用Stream的平行，也不一定直接用ForkJoinExecutor。用CompletableFuture + Sequencial Stream也可以輕鬆善用CPU Multicore的好處。

回應 9 years ago

howie 積分 0

恩我看到文章是很多地方雖然可以parallel但是會被content switch...等問提把好處都消耗光~所以真的很難說...

回應 9 years ago

caterpillar 積分 3

執行資料平行處理的效能考量1 有談一些，也可以参考《Java 8 Lambdas》那本書中對效能的討論。

回應 9 years ago

kaif 積分 0

Java 8 Lambdas有提到，如果程式是多個loop去串接的，此時用Internal iteration可以惰性求值，因此性能有機會優於external loop。書上沒有提供測試數據，僅是定性的敘述。

回應 9 years ago

koji 積分 2

他跑的次數太大了，正常來說整個功能中這些 stream 的動作應該不會是最大的比重。如果是我，我應該會先把其他效能瓶頸都處理完後才會去擔心這部分。

回應 9 years ago

popcorny 積分 1

同意。他的例子是極端簡單的iteration,且跑10M次，才會覺得改善顯著。但一般情況可能I/O, decompress, deserialize, string processing這些都完全大於stream overhead

回應 9 years ago

Kmark 是一個類似 Markdown 語法的格式，以下為提供的功能:

種類	語法	呈現
斜體	兩邊加單星	兩邊加單星
粗體	兩邊加雙星	兩邊加雙星
刪除線	~~兩邊加雙曲號~~	~~兩邊加雙曲號~~
引用	> 左邊加個大於符號	左邊加個大於符號
列表	* 可用星號 * 也可以 - 減號 * 數字加點也可以	可用星號也可以 - 減號數字加點也可以
固定寬字	`abcdefghijk` 兩邊用倒引號包住	`abcdefghijk`
編碼區塊	``` function abc() ``` 上下都用三個倒引號包住	`function abc()`
連結	[這是連結][1] [1]: http://example.com 連結第一部份是文字，先用中括號包住，後面再加上 [編號]。第二部份是連結本身，放在文末，開頭是 [編號]: http	這是連結1 1 http://example.com

Kmark 是一個類似 Markdown 語法的格式，以下為提供的功能:

種類	語法	呈現
斜體	兩邊加單星	兩邊加單星
粗體	兩邊加雙星	兩邊加雙星
刪除線	~~兩邊加雙曲號~~	~~兩邊加雙曲號~~
引用	> 左邊加個大於符號	左邊加個大於符號
列表	* 可用星號 * 也可以 - 減號 * 數字加點也可以	可用星號也可以 - 減號數字加點也可以
固定寬字	`abcdefghijk` 兩邊用倒引號包住	`abcdefghijk`
編碼區塊	``` function abc() ``` 上下都用三個倒引號包住	`function abc()`
連結	[這是連結][1] [1]: http://example.com 連結第一部份是文字，先用中括號包住，後面再加上 [編號]。第二部份是連結本身，放在文末，開頭是 [編號]: http	這是連結1 1 http://example.com