Scala 生产代码中的流

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

是的，我使用它，尽管它通常用于类似这样的用途：

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

---

当然，对于本例，我可能会使用非严格视图和

查找
，因为不使用
流的唯一原因是，要确保JVM不保留对早期conse的引用可能很棘手，我使用的一种非常好的方法是建立
流
，并立即将其转换为
迭代器
，以供实际使用。它在使用方面损失了一点
流
的优良特性，特别是在回溯方面，但是如果只对结果进行一次传递，那么以这种方式构建结构通常比扭曲到
hasNext
/
next（）
迭代器的模型直接使用。
尽管我写过，我确实在生产代码中使用了
流。我只是不自动地假设这些细胞是垃圾收集的

有时
Stream
非常适合这个问题。我认为api给出了涉及递归的地方…
流没有问题，除非人们使用它来替换迭代器，而不是替换与它最相似的集合。在这种特殊情况下，使用时必须小心。另一方面，也必须小心使用
迭代器，因为每个元素只能迭代一次

那么，既然两者都有各自的问题，为什么要挑出
Stream
？我敢说，这只是因为人们习惯于使用Java的迭代器，而流是一种功能性的东西。这篇博文介绍了如何使用Scala流（以及内存映射文件）高效地读取大型文件（1-2G）

我还没有试过，但解决方案看起来是合理的。Stream在低级的
ByteBuffer
JavaAPI之上提供了一个很好的抽象，可以将内存映射文件作为一个记录序列来处理。
Stream
有什么特别之处，让您提出这个问题？为什么不应该在生产代码中使用它呢？很容易耗尽内存。我似乎还记得读到过，它的实现正在显示出它的时代。所以我只是好奇人们是否真的将其用于Euler项目之外的事情感谢与另一个问题的链接，非常有帮助。我想激励我的是意识到流在内存使用方面是如此脆弱，以至于在生产代码中发现它时我会不寒而栗，除非没有其他方法。好吧，流似乎有它的问题，例如在reduceLeft中使用时。这个问题有很多很好的答案；这对我来说是最有帮助的，因为我并不认为像列表一样使用它，而不是迭代器，是正确的方法。感谢所有回复的人。