Java 8 - 转换列表的最佳方法:map或foreach?

时间:2015-02-04 10:30:05

标签: java java-8 java-stream

我有一个列表myListToParse,我希望在其中过滤元素并对每个元素应用方法,并将结果添加到另一个列表myFinalList中。

使用Java 8,我注意到我可以通过两种不同的方式实现它。我想知道他们之间更有效的方式,并理解为什么一种方式比另一种更好。

我愿意接受有关第三种方式的任何建议。

方法1:

myFinalList = new ArrayList<>();
myListToParse.stream()
        .filter(elt -> elt != null)
        .forEach(elt -> myFinalList.add(doSomething(elt)));

方法2:

myFinalList = myListToParse.stream()
        .filter(elt -> elt != null)
        .map(elt -> doSomething(elt))
        .collect(Collectors.toList()); 

8 个答案:

答案 0 :(得分:133)

不要担心任何性能差异,在这种情况下它们通常会很小。

方法2是优选的,因为

  1. 它不需要改变存在于lambda表达式之外的集合,

  2. 它更具可读性,因为在集合管道中执行的不同步骤是按顺序写入的(首先是过滤操作,然后是映射操作,然后收集结果), (有关收集管道的好处的更多信息,请参阅Martin Fowler的excellent article

  3. 您可以通过替换使用的Collector轻松更改收集值的方式。在某些情况下,您可能需要编写自己的Collector,但其好处是您可以轻松地重复使用它。

答案 1 :(得分:39)

我同意现有的答案,第二种形式更好,因为它没有任何副作用,更容易并行化(只使用并行流)。

性能方面,在您开始使用并行流之前,它们似乎是等效的。在这种情况下,地图的效果会更好。请参阅下面的micro benchmark结果:

Benchmark                         Mode  Samples    Score   Error  Units
SO28319064.forEach                avgt      100  187.310 ± 1.768  ms/op
SO28319064.map                    avgt      100  189.180 ± 1.692  ms/op
SO28319064.mapWithParallelStream  avgt      100   55,577 ± 0,782  ms/op

你不能以相同的方式提升第一个例子,因为 forEach 是一个终端方法 - 它返回void - 所以你被迫使用有状态的lambda。但是that is really a bad idea if you are using parallel streams

最后请注意,您的第二个代码段可以使用方法引用和静态导入以更简洁的方式编写:

myFinalList = myListToParse.stream()
    .filter(Objects::nonNull)
    .map(this::doSomething)
    .collect(toList()); 

答案 2 :(得分:5)

使用流的一个主要好处是它能够以声明的方式处理数据,即使用函数式编程。它还提供免费的多线程功能,这意味着无需编写任何额外的多线程代码来使您的流并发。

假设您正在探索这种编程风格的原因是您希望利用这些优势,那么您的第一个代码示例可能无法正常运行,因为foreach方法被归类为终端(意味着它可以产生一面)效果 - )。

从功能编程的角度来看,第二种方式是首选,因为map函数可以接受无状态lambda函数。更明确地说,传递给map函数的lambda应该是

  1. 非干扰,意味着如果非并发(例如ArrayList),该函数不应更改流的来源。
  2. 无状态以避免在执行并行处理时出现意外结果(由线程调度差异引起)。
  3. 第二种方法的另一个好处是,如果流是并行的,并且收集器是并发和无序的,那么这些特性可以为还原操作提供有用的提示,以便同时进行收集。

答案 3 :(得分:4)

如果您使用Eclipse Collections,则可以使用collectIf()方法。

MutableList<Integer> source =
    Lists.mutable.with(1, null, 2, null, 3, null, 4, null, 5);

MutableList<String> result = source.collectIf(Objects::nonNull, String::valueOf);

Assert.assertEquals(Lists.immutable.with("1", "2", "3", "4", "5"), result);

它急切地评估,并且应该比使用Stream快一点。

注意:我是Eclipse Collections的提交者。

答案 4 :(得分:1)

我更喜欢第二种方式。

当您使用第一种方式时,如果您决定使用并行流来提高性能,则无法控制forEach将元素添加到输出列表的顺序。

当您使用toList时,即使您使用并行流,Streams API也会保留订单。

答案 5 :(得分:0)

还有第三个选项 - 使用stream().toArray() - 请参阅why didn't stream have a toList method下的评论。事实证明它比forEach()或collect()慢,而且表现力较差。它可能在以后的JDK构建中进行了优化,因此在此处添加它以防万一。

假设List<String>

    myFinalList = Arrays.asList(
            myListToParse.stream()
                    .filter(Objects::nonNull)
                    .map(this::doSomething)
                    .toArray(String[]::new)
    );

使用micro-micro基准测试,1M条目,20%nulls和doSomething中的简单转换()

private LongSummaryStatistics benchmark(final String testName, final Runnable methodToTest, int samples) {
    long[] timing = new long[samples];
    for (int i = 0; i < samples; i++) {
        long start = System.currentTimeMillis();
        methodToTest.run();
        timing[i] = System.currentTimeMillis() - start;
    }
    final LongSummaryStatistics stats = Arrays.stream(timing).summaryStatistics();
    System.out.println(testName + ": " + stats);
    return stats;
}

结果

平行:

toArray: LongSummaryStatistics{count=10, sum=3721, min=321, average=372,100000, max=535}
forEach: LongSummaryStatistics{count=10, sum=3502, min=249, average=350,200000, max=389}
collect: LongSummaryStatistics{count=10, sum=3325, min=265, average=332,500000, max=368}

顺序:

toArray: LongSummaryStatistics{count=10, sum=5493, min=517, average=549,300000, max=569}
forEach: LongSummaryStatistics{count=10, sum=5316, min=427, average=531,600000, max=571}
collect: LongSummaryStatistics{count=10, sum=5380, min=444, average=538,000000, max=557}

parallel没有空值和过滤器(因此流是SIZED): 在这种情况下,toArrays具有最佳性能,.forEach()在接收者ArrayList上失败并带有“indexOutOfBounds”,必须替换为.forEachOrdered()

toArray: LongSummaryStatistics{count=100, sum=75566, min=707, average=755,660000, max=1107}
forEach: LongSummaryStatistics{count=100, sum=115802, min=992, average=1158,020000, max=1254}
collect: LongSummaryStatistics{count=100, sum=88415, min=732, average=884,150000, max=1014}

答案 6 :(得分:0)

可能是方法3。

我总是喜欢将逻辑分开。

Predicate<Long> greaterThan100 = new Predicate<Long>() {
            @Override
            public boolean test(Long currentParameter) {
                return currentParameter > 100;
            }
        };

        List<Long> sourceLongList = Arrays.asList(1L, 10L, 50L, 80L, 100L, 120L, 133L, 333L);
        List<Long> resultList = sourceLongList.parallelStream().filter(greaterThan100).collect(Collectors.toList());

答案 7 :(得分:0)

如果使用3rd Pary Libaries,那么cyclops-react定义了内置此功能的Lazy扩展集合。例如,我们可以简单地编写

ListX myListToParse;

ListX myFinalList = myListToParse.filter(elt - &gt; elt!= null)                                  .map(elt - &gt; doSomething(elt));

myFinalList在第一次访问之前不会被评估(在物化列表被高速缓存并重新使用之后)。

[披露我是独眼巨人反应的主要开发者]