foreach用法_为什么不应该用Stream forEach替换for循环的3个原因

最新推荐文章于 2024-08-21 00:01:29 发布

cunhu4317

最新推荐文章于 2024-08-21 00:01:29 发布

阅读量899

点赞数

文章标签： python java 编程语言人工智能设计模式

原文链接： https://www.javacodegeeks.com/2015/12/3-reasons-shouldnt-replace-loops-stream-foreach.html

版权

foreach用法

太棒了！我们正在将代码库迁移到Java8。我们将用函数替换所有内容。扔掉设计模式。删除面向对象。对！我们走吧！

等一下

Java 8已经问世了一年多，而这种兴奋又回到了日常业务中。

baeldung.com从2015年5月开始执行的一项非代表性研究发现，他们的读者中有38％的人已经采用Java 8 。在此之前，Typsafe在2014年末进行的一项研究声称，其用户中Java 8的采用率为27％。

这对您的代码库意味着什么？

某些Java 7-> Java 8迁移重构是理所当然的。例如，将Callable传递给ExecutorService ：

ExecutorService s = ...

// Java 7 - meh...
Future<String> f = s.submit(
    new Callable<String>() {
        @Override
        public String call() {
            return "Hello World";
        }
    }
);

// Java 8 - of course!
Future<String> f = s.submit(() -> "Hello World");

匿名类样式实际上在这里没有添加任何值。

除了这些容易理解的话题之外，还有其他不太明显的话题。例如，是否使用外部迭代器还是内部迭代器。另请参阅Neil Gafter于2007年发表的有关永恒主题的有趣读物： http ://gafter.blogspot.ch/2007/07/internal-versus-external-iterators.html

以下两个逻辑的结果相同

List<Integer> list = Arrays.asList(1, 2, 3);

// Old school
for (Integer i : list)
    System.out.println(i);

// "Modern"
list.forEach(System.out::println);

我主张“现代”方法应格外小心，即只有在您真正从内部功能迭代中受益时(例如，通过Stream的map() ， flatMap()和其他操作链接一组操作map() ，才应格外小心。

与经典方法相比，这是“现代”方法的缺点的简短列表：

1.绩效–您会因此而损失

Angelika Langer在她的文章以及她在会议上发表的相关演讲中已经很好地总结了这个主题：

https://jaxenter.com/java-performance-tutorial-how-fast-are-the-java-8-streams-118830.html

在许多情况下，性能并不重要，因此您不应该进行任何过早的优化-因此您可能会声称此参数本身并不是真正的参数。但是在这种情况下，我会反驳这种态度，说Stream.forEach()与普通的for循环相比的开销是如此之大，以至于默认情况下使用它只会在您所有的CPU上堆积很多无用的CPU周期应用。如果仅根据循环样式的选择来谈论将CPU消耗增加10％-20％，那么我们所做的根本就是错误的。是的–各个循环无关紧要，但是可以避免整个系统的负担。

这是Angelika在普通循环上的基准测试结果，在装箱的整数列表中找到最大值：

ArrayList, for-loop : 6.55 ms
ArrayList, seq. stream: 8.33 ms

在其他情况下，当我们对原始数据类型执行相对简单的计算时，我们绝对应该退回到经典的for循环(最好是数组而不是集合)。

这是Angelika在普通循环上的基准测试结果，在原始整数数组中找到最大值：

int-array, for-loop : 0.36 ms
int-array, seq. stream: 5.35 ms

过早的优化效果不好，但避免过早优化的货运教育更加糟糕。重要的是要反思我们所处的环境，并在这种环境下做出正确的决定。我们之前已经写过关于性能的博客，请参阅我们的文章《 Java十大简单性能优化》

2.可读性–至少对于大多数人而言

我们是软件工程师。我们将始终讨论我们的代码样式，就像它真的很重要一样。例如，空格或花括号。

我们这样做的原因是因为软件维护很困难。特别是别人编写的代码。很久以前。在切换到Java之前，谁可能只写了C代码。

当然，在到目前为止的示例中，我们确实没有可读性问题，这两个版本可能是等效的：

List<Integer> list = Arrays.asList(1, 2, 3);

// Old school
for (Integer i : list)
    System.out.println(i);

// "Modern"
list.forEach(System.out::println);

但是这里发生了什么：

List<Integer> list = Arrays.asList(1, 2, 3);

// Old school
for (Integer i : list)
    for (int j = 0; j < i; j++)
        System.out.println(i * j);

// "Modern"
list.forEach(i -> {
    IntStream.range(0, i).forEach(j -> {
        System.out.println(i * j);
    });
});

事情开始变得更加有趣和异常。我不是说“更糟”。这是实践和习惯的问题。而且没有黑/白问题的答案。但是，如果其余代码库是必须的(可能是这样)，则嵌套范围声明和forEach()调用以及lambda肯定是不寻常的，这会在团队中引起认知冲突。

您可以构建一些示例，其中命令式方法比等效的功能式方法感觉更尴尬，如此处所示：

势在必行–功能分离 pic.twitter.com/G2cC6iBkDJ

— Mario Fusco(@mariofusco) 2015年3月1日

但是在很多情况下，这是不正确的，并且要编写功能上相对简单的命令相当的命令相当困难(同样，效率低下)。可以在此博客的先前文章中看到一个示例： http : //blog.jooq.org/2015/09/09/how-to-use-java-8-functional-programming-to-generate-an-alphabetic -顺序/

在那篇文章中，我们生成了一个字符序列：

A, B, ..., Z, AA, AB, ..., ZZ, AAA

…类似于MS Excel中的列：

命令式方法( 最初由Stack Overflow上的一个未命名用户使用)：

import static java.lang.Math.*;
 
private static String getString(int n) {
    char[] buf = new char[(int) floor(log(25 * (n + 1)) / log(26))];
    for (int i = buf.length - 1; i >= 0; i--) {
        n--;
        buf[i] = (char) ('A' + n % 26);
        n /= 26;
    }
    return new String(buf);
}

……在简洁性上可能胜过功能性的：

import java.util.List;
 
import org.jooq.lambda.Seq;
 
public class Test {
    public static void main(String[] args) {
        int max = 3;
 
        List<String> alphabet = Seq
            .rangeClosed('A', 'Z')
            .map(Object::toString)
            .toList();
 
        Seq.rangeClosed(1, max)
           .flatMap(length ->
               Seq.rangeClosed(1, length - 1)
                  .foldLeft(Seq.seq(alphabet), (s, i) -> 
                      s.crossJoin(Seq.seq(alphabet))
                       .map(t -> t.v1 + t.v2)))
           .forEach(System.out::println);
    }
}

并且这已经在使用 jOOλ ，以简化功能Java的编写。

3.可维护性

让我们再次考虑前面的示例。现在，我们不再对值相乘，而是对它们进行除法。

List<Integer> list = Arrays.asList(1, 2, 3);

// Old school
for (Integer i : list)
    for (int j = 0; j < i; j++)
        System.out.println(i / j);

// "Modern"
list.forEach(i -> {
    IntStream.range(0, i).forEach(j -> {
        System.out.println(i / j);
    });
});

显然，这是自找麻烦，我们可以在异常堆栈跟踪中立即看到问题。

老套

Exception in thread "main" java.lang.ArithmeticException: / by zero
	at Test.main(Test.java:13)

现代

Exception in thread "main" java.lang.ArithmeticException: / by zero
	at Test.lambda$1(Test.java:18)
	at java.util.stream.Streams$RangeIntSpliterator.forEachRemaining(Streams.java:110)
	at java.util.stream.IntPipeline$Head.forEach(IntPipeline.java:557)
	at Test.lambda$0(Test.java:17)
	at java.util.Arrays$ArrayList.forEach(Arrays.java:3880)
	at Test.main(Test.java:16)

哇。我们只是…吗？是。这就是为什么我们首先在项目1中遇到性能问题的原因。对于JVM和库，内部迭代只是要做很多工作。这是一个非常简单的用例，我们可以用AA, AB, .., ZZ系列的产品展示同样的东西。

从维护的角度来看，函数式编程风格比命令式编程要困难得多，尤其是当您在传统代码中盲目地将两种风格混合在一起时。