在生产代码中流式传输答案

【问题标题】：Stream in production code在生产代码中流式传输
【发布时间】：2011-03-20 18:57:05
【问题描述】：

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

【问题讨论】：

Stream 有什么特别之处让您提出这个问题？为什么不应该在生产代码中使用它？
一个人很容易耗尽内存。我似乎还记得读过它的实施正在显示它的年龄。所以我只是好奇人们是否真的将它用于欧拉计划之外的事情。 ;)

标签： scala

【解决方案1】：

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

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

【讨论】：

嗯，Stream 似乎确实有它的问题，比如在 reduceLeft 中使用时。
这个问题有很多很好的答案；这个对我来说是最有帮助的，因为我不太明白像使用列表而不是迭代器那样使用它是正确的方法。感谢所有回复的人。

【解决方案2】：

尽管我写了 Iterator is what I want to use nearly all the time，但我确实在生产代码中使用了 Stream。我只是不会自动假设单元格是垃圾收集的。

有时Stream 非常适合这个问题。我认为 api 在涉及递归的地方给出了some good examples...

【讨论】：

感谢其他问题的链接，非常有帮助。

【解决方案3】：

看here。这篇博文描述了如何使用 Scala Streams（连同内存映射文件）来有效地读取大文件（1-2G）。

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

【讨论】：

【解决方案4】：

是的，我使用它，虽然它往往是这样的：

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

当然，对于这个例子，我可能会使用非严格视图和find

【讨论】：

我想激励我的原因是意识到 Stream 在内存使用方面是如此脆弱，除非没有其他方法，否则我会不寒而栗地在生产代码中找到它。

【解决方案5】：

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

【讨论】：