Java 8 次直播时间和原因
Java 8 streams when and why
我最近开始从事一个项目，他们鼓励使用流 lambda 等编写代码。基本上，函数式编程方法。虽然我发现流很吸引人，但我对它们有一些疑问。他们如下。
性能 - 串行流真的比相应的 collection 更快、更具可扩展性吗？或者流只是更可取，因为有一天我们可能会使用 stream().parallel() 版本？
内存使用 - 流是否对堆内存造成负担，因为像 collect(toList()) 这样的终端操作通常会创建一个新的 object?
垃圾 collection (GC) - 流是否比 collections 对 GC 更友好？
编程范式 - 我个人认为将函数式编程风格与 OOP 混合会导致一些问题。
调试 - 我个人用笔和纸调试我的代码，而不是使用调试器（有些人可能更喜欢调试器）。流在调试方面有多好？
操作复杂性 - 在编写日常代码时（过滤分组收集映射）流是小菜一碟，但我发现当我必须写复杂的逻辑我最终采用了旧的基于 collection 的方法，因为它更易于调整。只有我这样做吗？
我知道我在这里问了多个问题，但实际上它们是标题中提到的同一个问题的 6 个部分。希望至少对每个 sub-questions 有一个类似答案的总结。如果有人也可以添加 link 来深入了解所有这些内容，那将会很有帮助。
干杯！！
Performance - are serial streams really faster and more scalable than corresponding collections?
没有。至少，平均而言不是......当前的 Stream 实现。
Or are streams only preferable because someday we might use the stream().parallel() version?
可能是的。但是，对于许多用例，使用 parallel() 的开销超过了可能的加速。
Memory usage - are streams a burden on the heap memory given that the terminal operations like collect(toList()) usually create a new object?
据我所知，不会。内存使用量通常不会减少。
Garbage collection (GC) - are streams more GC friendly than collections?
据我所知，没有。
Programming paradigm - I personally think mixing the functional programming style with OOPs is kind of gonna result in issues.
这是你的意见。
如果您坚持让流操作没有副作用，就不会有任何问题。
- 文档建议反对流操作中的副作用。
- 如果你依赖副作用，那是行不通的。
Debugging - I personally debug my code by pen and paper rather than using a debugger (which some people might prefer). How good are streams when it comes to debugging?
这是一个见仁见智的问题。我个人认为对调试没有影响
Operations Complexity - when it comes to writing everyday code (filtering grouping collecting mapping) streams are a cakewalk, but I find that when I have to write complex logic I end up resorting to the old collection based approach as it is more tweakable. Am I the only one doing this?
你不是唯一一个。另一方面，很多人使用比简单的过滤、分组、收集和映射更复杂的东西。使用流的次数越多， 就能更好地发现其他用例。但不利的一面是，有些人似乎想用流做一些他们可能不应该做的事情。
I recently started working on a project where they encourage writing code with streams lambdas and such.
这是你和团队其他成员之间的事情。我不认为我/我们的职责是参与您的项目团队对此的辩论。
Java 流的主要好处之一是它们将实时处理数据。例如，假设您有一个包含 1000 个数据点的数组。如果您要使用传统方法处理它，则需要批处理。这意味着在处理完所有项目之前，您不会获得第一个处理项目的结果。正如您可以想象的那样，这会大大降低速度，尤其是当您的方法是管道的一部分时。假设这个方法需要 10 分钟（极端例子来证明一个观点）来完成。另外，假设这是 20 个不同流程中的第一个，每个流程花费的时间大致相同。您正在寻找 200 分钟来处理一个数组。
现在想象一下同一个管道，所有进程都花费相同的时间，但不是批处理，而是流式传输数据。这涉及通过一个函数一个一个地处理数组项。结果是，一旦您的第一个项目完成，它就可以继续流程中的下一个点。在我们的示例中，第一项可能会在几秒钟内完成。无需等待 999 条其他数据处理，它可以立即移动到链中的下一个 Link。这确保了链后端的进程被阻塞的时间更短。
显然，这是一个理论上的例子。因此，它不会考虑诸如线程阻塞之类的问题。但是，能够 运行 对一个集合同时进行多个进程的优势仍然很大。
这也是 Java 流的大多数函数将 return 流的原因。它们被设计成 运行 在某种管道中
我最近开始从事一个项目，他们鼓励使用流 lambda 等编写代码。基本上，函数式编程方法。虽然我发现流很吸引人，但我对它们有一些疑问。他们如下。
性能 - 串行流真的比相应的 collection 更快、更具可扩展性吗？或者流只是更可取，因为有一天我们可能会使用 stream().parallel() 版本？
内存使用 - 流是否对堆内存造成负担，因为像 collect(toList()) 这样的终端操作通常会创建一个新的 object?
垃圾 collection (GC) - 流是否比 collections 对 GC 更友好？
编程范式 - 我个人认为将函数式编程风格与 OOP 混合会导致一些问题。
调试 - 我个人用笔和纸调试我的代码，而不是使用调试器（有些人可能更喜欢调试器）。流在调试方面有多好？
操作复杂性 - 在编写日常代码时（过滤分组收集映射）流是小菜一碟，但我发现当我必须写复杂的逻辑我最终采用了旧的基于 collection 的方法，因为它更易于调整。只有我这样做吗？
我知道我在这里问了多个问题，但实际上它们是标题中提到的同一个问题的 6 个部分。希望至少对每个 sub-questions 有一个类似答案的总结。如果有人也可以添加 link 来深入了解所有这些内容，那将会很有帮助。
干杯！！
Performance - are serial streams really faster and more scalable than corresponding collections?
没有。至少，平均而言不是......当前的 Stream 实现。
Or are streams only preferable because someday we might use the
stream().parallel()version?
可能是的。但是，对于许多用例，使用 parallel() 的开销超过了可能的加速。
Memory usage - are streams a burden on the heap memory given that the terminal operations like collect(toList()) usually create a new object?
据我所知，不会。内存使用量通常不会减少。
Garbage collection (GC) - are streams more GC friendly than collections?
据我所知，没有。
Programming paradigm - I personally think mixing the functional programming style with OOPs is kind of gonna result in issues.
这是你的意见。
如果您坚持让流操作没有副作用，就不会有任何问题。
- 文档建议反对流操作中的副作用。
- 如果你依赖副作用，那是行不通的。
Debugging - I personally debug my code by pen and paper rather than using a debugger (which some people might prefer). How good are streams when it comes to debugging?
这是一个见仁见智的问题。我个人认为对调试没有影响
Operations Complexity - when it comes to writing everyday code (filtering grouping collecting mapping) streams are a cakewalk, but I find that when I have to write complex logic I end up resorting to the old collection based approach as it is more tweakable. Am I the only one doing this?
你不是唯一一个。另一方面，很多人使用比简单的过滤、分组、收集和映射更复杂的东西。使用流的次数越多， 就能更好地发现其他用例。但不利的一面是，有些人似乎想用流做一些他们可能不应该做的事情。
I recently started working on a project where they encourage writing code with streams lambdas and such.
这是你和团队其他成员之间的事情。我不认为我/我们的职责是参与您的项目团队对此的辩论。
Java 流的主要好处之一是它们将实时处理数据。例如，假设您有一个包含 1000 个数据点的数组。如果您要使用传统方法处理它，则需要批处理。这意味着在处理完所有项目之前，您不会获得第一个处理项目的结果。正如您可以想象的那样，这会大大降低速度，尤其是当您的方法是管道的一部分时。假设这个方法需要 10 分钟（极端例子来证明一个观点）来完成。另外，假设这是 20 个不同流程中的第一个，每个流程花费的时间大致相同。您正在寻找 200 分钟来处理一个数组。
现在想象一下同一个管道，所有进程都花费相同的时间，但不是批处理，而是流式传输数据。这涉及通过一个函数一个一个地处理数组项。结果是，一旦您的第一个项目完成，它就可以继续流程中的下一个点。在我们的示例中，第一项可能会在几秒钟内完成。无需等待 999 条其他数据处理，它可以立即移动到链中的下一个 Link。这确保了链后端的进程被阻塞的时间更短。
显然，这是一个理论上的例子。因此，它不会考虑诸如线程阻塞之类的问题。但是，能够 运行 对一个集合同时进行多个进程的优势仍然很大。
这也是 Java 流的大多数函数将 return 流的原因。它们被设计成 运行 在某种管道中