当前位置：文江博客话题详情

生产代码中的流式传输

发布于 2024-10-24 07:55:29 字数 51 浏览 2 评论 0原文

人们真的在生产代码中使用 Scala 的 Stream 类吗？或者它主要是出于学术兴趣？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

似梦非梦 2024-10-31 07:55:29

Stream 没有问题，除非人们用它来替换 Iterator ——而不是替换 List，后者是最类似于的集合它。在这种特殊情况下，人们在使用时必须小心。另一方面，使用迭代器也必须小心，因为每个元素只能迭代一次。

那么，既然两者都有自己的问题，为什么要单独挑选 Stream 呢？我敢说这只是人们习惯了 Java 中的 Iterator，而 Stream 是一个函数式的东西。

回复收藏 0 原文

江湖彼岸 2024-10-31 07:55:29

即使我写了迭代器是我的几乎所有时间都想使用我确实在生产代码中使用Stream。我只是不会自动假设单元格已被垃圾收集。

有时 Stream 可以完美地解决这个问题。我认为 api 提供了一些很好的例子涉及递归的地方...

回复收藏 0 原文

热血少△年 2024-10-31 07:55:29

请查看此处。这篇博文介绍了如何使用 Scala Streams（以及内存映射文件）高效读取大文件 (1-2G)。

我还没有尝试过，但解决方案看起来很合理。 Stream 在低级 ByteBuffer Java API 之上提供了一个很好的抽象，用于将内存映射文件作为记录序列进行处理。

回复收藏 0 原文

感情废物 2024-10-31 07:55:29

是的，我使用它，尽管它往往用于类似这样的事情：

(as.toStream collect expensiveConversionToB) match {
  case b #:: _ => //found my expensive b
  case _       =>
}

当然，在此示例中我可能会使用非严格视图和 find

Yes, I use it, although it tends to be for something like this:

(as.toStream collect expensiveConversionToB) match {
  case b #:: _ => //found my expensive b
  case _       =>
}

Of course, I might use a non-strict view and a find for this example

回复收藏 0 原文

ゞ花落谁相伴 2024-10-31 07:55:29

由于不使用 Stream 的唯一原因是确保 JVM 不会保留对早期 conses 的引用可能很棘手，因此我使用过的一种相当不错的方法是构建一个Stream 并立即将其转换为 Iterator 以供实际使用。它在使用方面失去了一些 Stream 的良好属性，尤其是在回溯方面，但如果您只想对结果进行一次传递，那么以这种方式构建结构通常会更容易而不是直接扭曲成 Iterator 的 hasNext/next() 模型。