用于大数据量的MemoryStream的替代方案

程序员过于努力地避免使用文件。在Windows中，内存和文件之间的区别很小。事实上，用于MemoryStream的任何内存都需要一个文件。存储由分页文件c:''pagefile.sys支持。反之亦然，您使用的任何文件都由内存支持。文件数据由文件系统缓存缓存在RAM中。因此，如果机器有足够的RAM，那么如果你使用FileStream，你实际上只能从内存中读写。并从使用内存中获得您期望的性能。它是完全免费的，你不必写任何代码来启用它，也不必管理它

如果机器没有足够的RAM，那么它也会以同样的方式退化。当你使用MemoryStream时，页面文件开始垃圾化，你会被磁盘拖慢。当您使用文件时，数据将无法容纳文件系统缓存，并且磁盘会降低您的速度。

你当然会得到使用文件的好处，你不会再耗尽内存了。请改用FileStream。

使用MemoryStream预计会发生这种情况，因此您应该实现自己的逻辑或使用一些外部类。这篇文章解释了MemoryStream和大数据的问题，并给出了MemoryStream的替代品MemoryStream

我们的团队遇到了类似的障碍。一些评论者建议开发人员在使用文件方面需要更加得心应手。如果直接使用文件系统是一种选择，那么就这样做，但这并不总是一种选择。

如果像我们需要的那样，您想在应用程序周围传递从文件读取的数据，则不能传递FileStream对象，因为它可能会在您读取数据之前被处理掉。我们最初使用MemoryStream来方便地传递数据，但也遇到了同样的问题。

我们使用了几种不同的解决方案来缓解这个问题。

我们使用的选项包括：

• 实现一个包装类，将数据存储在多个字节[]对象中（因为数组仍然限制为int.MaxValue个条目），并公开方法，使您几乎可以将它们视为流。我们仍然会不惜一切代价避免这种情况
• 使用某种"；令牌"；以传递对数据位置的引用并等待加载数据"；"及时"；在应用程序中

我建议看看这个项目。

http://www.codeproject.com/Articles/348590/A-replacement-for-MemoryStream

我认为内存流的问题来自于这样一个事实，即在它的下面，它们仍然是单个字节[]的花哨包装器，因此仍然受到.net的要求的约束，即即使在64位程序中，所有对象都必须小于2gb。上面的实现将字节[]分解为几个不同的字节[]。