我正在使用Java 8的流，無法理解我得到的性能結果。我有2個核心CPU（Intel i73520M），Windows 8 x64和64位Java 8 Update5。我正在對String的流/并行流進行簡單映射，發現并行版本要慢一些。Function<Stream<String>, Long> timeOperation = (Stream<String> stream) -> { long time1 = System.nanoTime(); final List<String> list = stream .map(String::toLowerCase) .collect(Collectors.toList()); long time2 = System.nanoTime(); return time2 - time1;};Consumer<Stream<String>> printTime = stream -> System.out.println(timeOperation.apply(stream) / 1000000f);String[] array = new String[1000000];Arrays.fill(array, "AbabagalamagA");printTime.accept(Arrays.stream(array)); // prints around 600printTime.accept(Arrays.stream(array).parallel()); // prints around 900考慮到我有2個CPU內核，并行版本是否應該更快？有人可以提示我為什么并行版本比較慢嗎？
3 回答
FFIVE
TA貢獻1797條經驗 獲得超6個贊
確實有幾個并行發生的問題。
首先是并行解決問題始終比順序執行涉及更多的實際工作。開銷涉及將工作劃分為多個線程，以及合并或合并結果。諸如將短字符串轉換為小寫字母之類的問題足夠小，以至于它們有被并行拆分開銷淹沒的危險。
第二個問題是，對Java程序進行基準測試非常微妙，并且很容易得出令人困惑的結果。兩個常見問題是JIT編譯和無效代碼消除。簡短的基準測試通常在JIT編譯之前或期間完成，因此它們無法衡量峰值吞吐量，實際上它們可能是在衡量JIT本身。當編譯發生時是不確定的，因此它也可能導致結果變化很大。
對于小型綜合基準，工作負載通常會計算被丟棄的結果。JIT編譯器非常擅長檢測到這一點，并消除了不會產生可在任何地方使用的結果的代碼。在這種情況下可能不會發生這種情況，但是如果您修改其他綜合工作負載，則肯定會發生。當然，如果JIT消除了基準測試工作量，它將使基準測試無用。
我強烈建議您使用完善的基準測試框架（例如JMH），而不是手動編寫一個自己的框架。JMH具有幫助避免常見基準測試陷阱（包括這些陷阱）的功能，并且很容易設置和運行。這是您轉換為使用JMH的基準：
package com.stackoverflow.questions;
import java.util.Arrays;
import java.util.List;
import java.util.stream.Collectors;
import java.util.concurrent.TimeUnit;
import org.openjdk.jmh.annotations.*;
public class SO23170832 {
@State(Scope.Benchmark)
public static class BenchmarkState {
static String[] array;
static {
array = new String[1000000];
Arrays.fill(array, "AbabagalamagA");
}
}
@GenerateMicroBenchmark
@OutputTimeUnit(TimeUnit.SECONDS)
public List<String> sequential(BenchmarkState state) {
return
Arrays.stream(state.array)
.map(x -> x.toLowerCase())
.collect(Collectors.toList());
}
@GenerateMicroBenchmark
@OutputTimeUnit(TimeUnit.SECONDS)
public List<String> parallel(BenchmarkState state) {
return
Arrays.stream(state.array)
.parallel()
.map(x -> x.toLowerCase())
.collect(Collectors.toList());
}
}
我使用命令運行此命令：
java -jar dist/microbenchmarks.jar ".*SO23170832.*" -wi 5 -i 5 -f 1
（這些選項指示5個熱身迭代，5個基準迭代和1個分叉的JVM。）在運行期間，JMH會發出很多詳細消息，而我已經忽略了這些消息?？偨Y結果如下。
Benchmark Mode Samples Mean Mean error Units
c.s.q.SO23170832.parallel thrpt 5 4.600 5.995 ops/s
c.s.q.SO23170832.sequential thrpt 5 1.500 1.727 ops/s
請注意，結果以每秒操作數為單位，因此看起來并行運行比順序運行快約三倍。但是我的機器只有兩個核心。嗯 而且每次運行的平均錯誤實際上大于平均運行時間！WAT？這里有些魚腥味。
這給我們帶來了第三個問題。仔細觀察工作負載，我們可以看到它為每個輸入分配了一個新的String對象，并且還將結果收集到一個列表中，該列表涉及大量的重新分配和復制。我猜想這將導致大量垃圾回收。通過在啟用了GC消息的情況下重新運行基準測試，我們可以看到以下內容：
java -verbose:gc -jar dist/microbenchmarks.jar ".*SO23170832.*" -wi 5 -i 5 -f 1
結果如下：
[GC (Allocation Failure) 512K->432K(130560K), 0.0024130 secs]
[GC (Allocation Failure) 944K->520K(131072K), 0.0015740 secs]
[GC (Allocation Failure) 1544K->777K(131072K), 0.0032490 secs]
[GC (Allocation Failure) 1801K->1027K(132096K), 0.0023940 secs]
# Run progress: 0.00% complete, ETA 00:00:20
# VM invoker: /Users/src/jdk/jdk8-b132.jdk/Contents/Home/jre/bin/java
# VM options: -verbose:gc
# Fork: 1 of 1
[GC (Allocation Failure) 512K->424K(130560K), 0.0015460 secs]
[GC (Allocation Failure) 933K->552K(131072K), 0.0014050 secs]
[GC (Allocation Failure) 1576K->850K(131072K), 0.0023050 secs]
[GC (Allocation Failure) 3075K->1561K(132096K), 0.0045140 secs]
[GC (Allocation Failure) 1874K->1059K(132096K), 0.0062330 secs]
# Warmup: 5 iterations, 1 s each
# Measurement: 5 iterations, 1 s each
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Throughput, ops/time
# Benchmark: com.stackoverflow.questions.SO23170832.parallel
# Warmup Iteration 1: [GC (Allocation Failure) 7014K->5445K(132096K), 0.0184680 secs]
[GC (Allocation Failure) 7493K->6346K(135168K), 0.0068380 secs]
[GC (Allocation Failure) 10442K->8663K(135168K), 0.0155600 secs]
[GC (Allocation Failure) 12759K->11051K(139776K), 0.0148190 secs]
[GC (Allocation Failure) 18219K->15067K(140800K), 0.0241780 secs]
[GC (Allocation Failure) 22167K->19214K(145920K), 0.0208510 secs]
[GC (Allocation Failure) 29454K->25065K(147456K), 0.0333080 secs]
[GC (Allocation Failure) 35305K->30729K(153600K), 0.0376610 secs]
[GC (Allocation Failure) 46089K->39406K(154624K), 0.0406060 secs]
[GC (Allocation Failure) 54766K->48299K(164352K), 0.0550140 secs]
[GC (Allocation Failure) 71851K->62725K(165376K), 0.0612780 secs]
[GC (Allocation Failure) 86277K->74864K(184320K), 0.0649210 secs]
[GC (Allocation Failure) 111216K->94203K(185856K), 0.0875710 secs]
[GC (Allocation Failure) 130555K->114932K(199680K), 0.1030540 secs]
[GC (Allocation Failure) 162548K->141952K(203264K), 0.1315720 secs]
[Full GC (Ergonomics) 141952K->59696K(159232K), 0.5150890 secs]
[GC (Allocation Failure) 105613K->85547K(184832K), 0.0738530 secs]
1.183 ops/s
注意：以開頭的行#是正常的JMH輸出線。其余所有都是GC消息。這只是五個預熱迭代中的第一個，它先于五個基準迭代。在其余的迭代過程中，GC消息以相同的方式繼續傳遞。我認為可以肯定地說，測得的性能主要由GC開銷決定，不應相信報告的結果。
目前尚不清楚該怎么做。這純粹是綜合性的工作量。顯然，與分配和復制相比，完成實際工作只需要很少的CPU時間。很難說您真正想在這里衡量什么。一種方法是提出在某種意義上更“真實”的不同工作負載。另一種方法是更改堆和GC參數，以避免在基準測試運行期間出現GC。
添加回答
舉報
0/150
提交
取消