快捷導(dǎo)航

Java8 如何正確高效的使用并行流

更新時(shí)間：2021年11月04日 16:11:38 作者：小小工匠

這篇文章主要介紹了Java8 如何正確高效的使用并行流，具有很好的參考價(jià)值，希望對大家有所幫助。如有錯(cuò)誤或未考慮完全的地方，望不吝賜教

正確使用并行流，避免共享可變狀態(tài)

錯(cuò)用并行流而產(chǎn)生錯(cuò)誤的首要原因，就是使用的算法改變了某些共享狀態(tài)。下面是另一種實(shí)現(xiàn)對前n個(gè)自然數(shù)求和的方法，但這會改變一個(gè)共享累加器：

public static long sideEffectSum(long n) {
	Accumulator accumulator = new Accumulator();
	LongStream.rangeClosed(1, n).forEach(accumulator::add);
	return accumulator.total;
}
public class Accumulator {
	public long total = 0;
	public void add(long value) { total += value; }
}

有什么問題呢？

它在本質(zhì)上就是順序的。每次訪問 total 都會出現(xiàn)數(shù)據(jù)競爭。如果用同步來修復(fù)，那就完全失去并行的意義了。

為了說明這一點(diǎn)，讓我們試著把 Stream 變成并行的：

public static long sideEffectParallelSum(long n) {
	Accumulator accumulator = new Accumulator();
	LongStream.rangeClosed(1, n).parallel().forEach(accumulator::add);
	return accumulator.total;
}

測試下，輸出

在這里插入圖片描述

性能無關(guān)緊要了，唯一要緊的是每次執(zhí)行都會返回不同的結(jié)果，都離正確值差很遠(yuǎn)。這是由于多個(gè)線程在同時(shí)訪問累加器，執(zhí)行 total += value ，而這卻不是一個(gè)原子操作。問題的根源在于， forEach 中調(diào)用的方法有副作用它會改變多個(gè)線程共享的對象的可變狀態(tài)。

要是你想用并行 Stream 又不想引發(fā)類似的意外，就必須避免這種情況。

所以共享可變狀態(tài)會影響并行流以及并行計(jì)算,要避免共享可變狀態(tài)，確保并行 Stream 得到正確的結(jié)果。

高效使用并行流

是否有必要使用并行流？

如果有疑問，多次測試結(jié)果。把順序流轉(zhuǎn)成并行流輕而易舉，但卻不一定是好事
留意裝箱。自動裝箱和拆箱操作會大大降低性能

Java 8中有原始類型流（ IntStream 、LongStream 、 DoubleStream ）來避免這種操作，但?有可能都應(yīng)該用這些流。

有些操作本身在并行流上的性能就比順序流差。特別是 limit 和 findFirst 等依賴于元素順序的操作，它們在并行流上執(zhí)行的代價(jià)非常大。

例如， findAny 會比 findFirst 性能好，因?yàn)樗灰欢ㄒ错樞騺韴?zhí)行。可以調(diào)用 unordered 方法來把有序流變成無序流。那么，如果你需要流中的n個(gè)元素而不是專門要前n個(gè)的話，對無序并行流調(diào)用limit 可能會比單個(gè)有序流（比如數(shù)據(jù)源是一個(gè) List ）更高效。