抛开语法方面的乐趣不谈，流的设计是为了处理可能无限大的数据集，而数组、集合和几乎所有实现iterable的javase类都完全在内存中。
流的一个缺点是过滤器、Map等不能抛出选中的异常。这使得流对于中间i/o操作来说是一个糟糕的选择。

在序列（数组、集合、输入等）上循环，因为要对序列的元素应用某些函数。
流使您能够在序列元素上组合函数，并允许独立于具体情况实现最常见的函数（例如，Map、过滤、查找、排序、收集等）。
因此，在大多数情况下，给定一些循环任务，您可以使用流以较少的代码来表达它，即获得可读性。

有趣的是，面试问题问的是优点，而不是缺点，因为两者都有。
流是一种更具声明性的样式。或者更具表现力的风格。在代码中声明您的意图可能比描述它是如何完成的要好：

return people
     .filter( p -> p.age() < 19)
     .collect(toList());

... 非常清楚地表明您正在从列表中筛选匹配的元素，而：

List<Person> filtered = new ArrayList<>();
 for(Person p : people) {
     if(p.age() < 19) {
         filtered.add(p);
     }
 }
 return filtered;

说“我在做循环”。循环的目的在逻辑中埋藏得更深。
溪流通常较短。同样的例子说明了这一点。简洁并不总是更好，但如果你能同时简洁和富有表现力，那就更好了。
流与函数有很强的亲和力。Java8引入了lambda和函数接口，这为强大的技术打开了一个完整的工具箱。流提供了将函数应用于对象序列的最方便和自然的方法。
流鼓励更少的易变性。这在某种程度上与函数式编程有关——使用流编写的程序往往是不修改对象的程序。
流鼓励松散耦合。流处理代码不需要知道流的源代码，也不需要知道流的最终终止方法。
流可以简洁地表达相当复杂的行为。例如：

stream.filter(myfilter).findFirst();

乍一看似乎它过滤了整个流，然后返回第一个元素。但事实上 findFirst() 驱动整个操作，因此它在找到一个项目后高效地停止。
溪流为未来效率的提高提供了空间。一些人做了基准测试，发现内存中的单线程流 List s或数组可以比等效循环慢。这是合理的，因为有更多的对象和间接费用在发挥作用。
但溪流规模很大。除了java内置的对并行流操作的支持之外，还有一些用于分布式map reduce的库使用流作为api，因为模型适合。
缺点？
性能：a for 通过数组的循环在堆和cpu使用方面都是非常轻量级的。如果优先考虑原始速度和内存节约，那么使用流就更糟了。
熟悉度。世界上充满了经验丰富的过程程序员，他们来自许多语言背景，对他们来说循环是熟悉的，流是新奇的。在某些环境中，您希望编写这种人熟悉的代码。
认知开销。由于它的声明性，以及从下面发生的事情中增加的抽象性，您可能需要构建一个新的思维模型来描述代码与执行的关系。实际上，您只需要在出现问题时，或者需要深入分析性能或细微缺陷时才需要这样做。当它“起作用”的时候，它就起作用了。
调试器正在改进，但即使是现在，当您在调试器中单步执行流代码时，也可能比等效循环更困难，因为简单循环非常接近传统调试器处理的变量和代码位置。

我认为它的并行化非常容易使用。尝试用for循环并行迭代数百万个条目。我们使用许多cpu，而不是更快；因此，并行运行越容易越好，而且 Stream 这是微风。
我最喜欢的是他们的冗长。了解他们实际做什么和生产什么只需要很少的时间，而不是他们是如何做的。

您错误地认识到：并行操作使用 Stream s、 不是 Optional s。
您可以定义处理流的方法：将它们作为参数，返回它们，等等。您不能定义将循环作为参数的方法。这允许一次使用一个复杂的流操作并多次使用它。注意，java在这里有一个缺点：您的方法必须作为 someMethod(stream) 相对于溪流本身 stream.someMethod() ，所以把它们混合在一起会使阅读复杂化：试着看一下

myMethod2(myMethod(stream.transform(...)).filter(...))

许多其他语言（c#、kotlin、scala等）允许某种形式的“扩展方法”。
即使您只需要顺序操作，并且不想重用它们，这样您就可以使用流或循环，流上的简单操作可能对应于循环中相当复杂的更改。