java流的一个主要好处是它们可以实时处理数据。例如，假设您有一个1000个数据点的数组。如果要用传统方法处理，则需要批处理。这意味着在处理完所有项之前，不会得到第一个已处理项的结果。正如您所想象的，这会大大降低速度，特别是当您的方法是管道的一部分时。假设这个方法需要10分钟（用极端的例子来证明一个观点）才能完成。另外，假设这是20个不同过程中的第一个，每个过程花费的时间大致相同。处理一个数组需要200分钟。
现在想象一下，同样的管道，所有的进程都花费同样的时间，但是你不是批量处理而是流式处理数据。这涉及到通过函数逐个处理数组项。其结果是，一旦你的第一项完成，它可以继续到下一个点的过程。在我们的示例中，第一项可能在几秒钟内完成。它可以立即移动到链中的下一个链接，而不是等待999个其他数据块进行处理。这确保了链后端的进程被阻塞的时间要短得多。
显然，这是一个理论上的例子。因此，它不考虑线程阻塞等问题。但是，能够在一个集合上同时运行多个进程的优势仍然很大。
这也是大多数java流函数返回流的原因。它们被设计成在一种管道中运行

性能-串行流真的比相应的集合更快、更具可伸缩性吗？
不，至少，不是一般的。。。使用当前的流实现。
或者只是因为有一天我们可能会使用 stream().parallel() 版本？
可能是的。然而，对于许多用例，使用 parallel() 超过可能的加速。
内存使用-如果collect（tolist（））这样的终端操作通常创建一个新对象，那么流是堆内存的负担吗？
好吧，不。通常不会减少内存使用。
垃圾收集（gc）-流比收集对gc更友好吗？
阿法克，不。
编程范式——我个人认为，将函数式编程风格与面向对象编程相结合会导致一些问题。
那是你的意见。
如果你坚持让你的流操作没有副作用，就不会有任何问题。
文档建议在流操作中避免副作用。
如果你依赖副作用，那就没用了。
调试-我个人用笔和纸调试代码，而不是使用调试器（有些人可能更喜欢）。在调试方面，流有多好？
那是意见的问题。我个人认为这对调试没有影响。
操作复杂度—当涉及到编写日常代码（过滤-分组-收集-Map）流时，这是一个棘手的问题，但我发现，当我必须编写复杂的逻辑时，我最终求助于旧的基于集合的方法，因为它更易于调整。我是唯一一个这样做的人吗？
你不是唯一一个。另一方面，很多人用它来做比简单的过滤、分组、收集和Map更复杂的事情。使用流越多，就越能更好地发现其他用例。但另一方面，有些人似乎想用流做一些他们可能不应该做的事情。
我最近开始从事一个项目，在这个项目中，他们鼓励使用streams lambdas等编写代码。
那是你和其他队员之间的事。我不认为这是我/我们的业务进入您的项目团队的辩论，在这个问题上。