for循环更具可读性。但是，根据我自己的经验和我所阅读的内容，使用流而不是for循环可能会导致性能损失（或偶尔会有改进），有时难以预测。
在一个大型项目中，为每个循环编写基准测试似乎不可行，所以在决定是否用流替换for循环时，关键因素是什么？ / strong>（例如，预期的集合大小，通过过滤删除的值的预期百分比，迭代操作的复杂性，减少或聚合的类型等）可能表示将导致的性能变化？
注意：这是my earlier question的缩小范围，因为过于宽泛而关闭（并且平行流的各个方面已经很好地覆盖了in another SO question），所以让＆＃39 ; s只是将其限制为顺序流。
答案 0 :(得分：20)
这不仅“为每个循环编写基准测试都不可行”，而且反效果。特定的，特定于应用程序的循环在进入微基准时可能会完全不同。
对于实际应用程序，标准优化规则适用：不执行。只需编写更易读的内容，只有存在性能问题时，才能整个应用程序来检查特定的循环或流是否确实是瓶颈。只有在这种情况下，您可以尝试在特定瓶颈的两个习语之间切换，看看它是否有所作为。
在大多数情况下，它不会。如果存在真正的性能问题，则将取决于操作类型，例如：执行具有O(n²)时间复杂度等的嵌套迭代。此类问题不取决于您是使用Stream还是for循环，而是这两个习惯用语之间的微小性能差异t改变代码缩放的方式。
答案 1 :(得分：6)
streams和loops之间的一般速度差异不大，它们的优点/缺点是特定于问题的。您是选择其中一个应该（主要）取决于代码的可读性。对于某些性能比较，请参阅Benchmark1和Benchmark2，您可以在其中注意到Brian Goetz对其中一个答案的评论：
关于表现的结论虽然有效但却被夸大了。在很多情况下，流代码比迭代代码更快，主要是因为流的每元素访问成本比使用普通迭代器更便宜。在许多情况下，流版本内联到与手写版本相同的内容。当然，魔鬼在于细节;任何给定的代码都可能表现不同。
除此之外，请确保在您进行基准测试时使用JMH。