Java 8 何时以及为什么流

如何解决Java 8 何时以及为什么流

我最近开始从事一个项目，他们鼓励使用 lambda 流等编写代码。基本上，函数式编程方法。虽然我发现流很有吸引力，但我对它们有一些疑问。它们如下。

1. 性能 - 串行流真的比相应的集合更快、更具可扩展性吗？或者流只是因为有一天我们可能会使用 stream().parallel() 版本？

2. 内存使用 - 考虑到像 collect(toList()) 这样的终端操作通常会创建一个新对象，流是堆内存的负担吗？

3. 垃圾回收 (GC) - 流是否比集合更适合 GC？

4. 编程范式 - 我个人认为将函数式编程风格与 OOP 混合会导致一些问题。

5. 调试 - 我个人用笔和纸调试我的代码，而不是使用调试器（有些人可能更喜欢）。流在调试方面有多好？

6. 操作复杂性 - 在编写日常代码（过滤分组收集映射）时，流是小菜一碟，但我发现当我必须编写复杂的逻辑时，我最终会求助于旧的基于集合的方法，因为它更易于调整。只有我一个人这样做吗？

我知道我在这里问了多个问题，但实际上它们是标题中提到的同一问题的 6 个部分。希望对这些子问题中的每一个都至少有一个总结般的答案。如果有人还可以添加链接以深入了解所有这些内容，那将会很有帮助。

干杯！！

解决方法

性能 - 串行流真的比相应的集合更快、更具可扩展性吗？

没有。至少，不是平均而言......使用当前的 Stream 实现。

或者流只是因为有一天我们可能会使用 stream().parallel() 版本？

可能是的。但是，对于许多用例，使用 parallel() 的开销超过了可能的加速。

内存使用 - 考虑到像 collect(toList()) 这样的终端操作通常会创建一个新对象，流是堆内存的负担吗？

AFAIK，不会。内存使用量通常不会减少。

垃圾收集 (GC) - 流是否比集合对 GC 更友好？

AFAIK，没有。

编程范式 - 我个人认为将函数式编程风格与 OOP 混合会导致一些问题。

这是你的意见。

如果你坚持让你的流操作没有副作用，就不会有任何问题。

• 文档建议防止流操作中的副作用。
• 如果你依赖副作用，那是没有用的。

调试 - 我个人用笔和纸调试我的代码，而不是使用调试器（有些人可能更喜欢）。流在调试方面有多好？

这是一个见仁见智的问题。我个人认为调试没有区别。

操作复杂性 - 在编写日常代码（过滤分组收集映射）时，流是小菜一碟，但我发现当我必须编写复杂的逻辑时，我最终会求助于旧的基于集合的方法，因为它更易于调整.只有我一个人这样做吗？

你不是唯一的。另一方面，很多人使用比简单的过滤、分组、收集和映射更复杂的事情。您使用流的次数越多，您就越能更好地发现其他用例。但另一方面，有些人似乎想用流来做他们可能不应该做的事情。

---

我最近开始参与一个项目，他们鼓励使用 lambda 流等编写代码。

那是你和团队其他成员之间的事情。我不认为参与你们项目团队的辩论是我/我们的事。

,

Java 流的主要好处之一是它们将实时处理数据。例如，假设您有一个包含 1000 个数据点的数组。如果您要使用传统方法进行处理，则需要批处理。这意味着在所有项目都处理完毕之前，您不会获得第一个处理项目的结果。可以想象，这会大大减慢速度，尤其是当您的方法是管道的一部分时。假设这个方法需要 10 分钟（极端例子证明一个观点）才能完成。另外，想象一下这是 20 个不同过程中的第一个，每个过程花费的时间大致相同。处理一个数组需要 200 分钟。

现在想象一下相同的管道，所有进程都花费相同的时间，但是您正在流式传输数据，而不是批处理。这涉及通过函数一个一个地处理数组项。结果是，一旦您的第一个项目完成，它就可以继续进行过程中的下一个点。在我们的示例中，第一项可能会在几秒钟内完成。它可以立即移动到链中的下一个链接，而不是等待 999 条其他数据进行处理。这确保了链后端的进程被阻塞的时间要短得多。

显然，这是一个理论上的例子。因此，它没有考虑线程阻塞等问题。但是，能够在一个集合上同时运行多个进程的优势仍然很大。

这也是为什么大多数 Java 流函数都会返回一个流的原因。它们被设计为在某种管道中运行