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 600
printTime.accept(Arrays.stream(array).parallel()); // prints around 900
考虑到我有2个CPU核心的事实,并行版本不是应该更快吗?有人能给我一个提示为什么并行版本比较慢吗?
事实上,这里有几个问题是并行的。
第一,并行解决一个问题总是需要执行更多的实际工作,而不是按顺序执行。在多个线程之间拆分工作以及连接或合并结果时会涉及开销。像将短字符串转换为小写的问题非常小,以至于它们有被并行拆分开销淹没的危险。
第二个问题是,对Java程序进行基准测试是非常微妙的,非常容易得到令人困惑的结果。两个常见的问题是JIT编译和死代码消除。短基准通常在JIT编译之前或期间完成,因此它们不是在测量峰值吞吐量,实际上它们可能是在测量JIT本身。编译发生的时间多少是不确定的,因此它也可能导致结果发生很大的变化。
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
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
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
问题内容: 我正在使用Java 8的流,无法理解我得到的性能结果。我有2个核心CPU(Intel i73520M),Windows 8 x64和64位Java 8 Update5。我正在对String的流/并行流进行简单映射,发现并行版本要慢一些。 考虑到我有2个CPU内核,并行版本是否应该更快?有人可以提示我为什么并行版本比较慢吗? 问题答案: 确实有几个并行发生的问题。 首先是并行解决问题总是
问题内容: 我在玩无限的流,并制作了该程序进行基准测试。基本上,您提供的数字越大,完成的速度就越快。但是,令我惊讶的是,与顺序流相比,使用并行流导致的性能成倍下降。凭直觉,人们期望在多线程环境中生成和评估无限快的随机数流,但是事实并非如此。为什么是这样? 问题答案: 我完全同意其他评论和答案,但实际上,如果目标很低,您的测试会表现得很奇怪。在我的普通笔记本电脑上,当给出非常低的目标时,并行版本平均
它们之间有什么相同和不同之处,看起来Java并行流中有RXJava中可用的一些元素,是吗?
我正在使用parallelStream并行上传一些文件,有些是大文件,有些是小文件。我注意到并不是所有的工人都被使用。 一开始一切都运行良好,所有线程都被使用(我将并行选项设置为16)。然后在某一点上(一旦它到达更大的文件),它只使用一个线程 简化代码: uploaderPool是一个ArrayBlockingQueue。日志: 似乎所有的工作(列表中的项目)都分布在16个线程中,委托给一个线程的
注意:这个问题源自一个死的链接,这是以前的一个SO问题,但这里是... 看到这段代码(注意:我确实知道这段代码不会“工作”,应该使用--我只是从链接的问题中提取出来的): 根据和的javadoc,两者的参数都应该是一个。然而,这里的方法引用是类的静态方法。