如果数据很大并且进程是 32 位，则在使用 .Net MemoryStream 时出现内存不足异常的问题。
我相信随着数据量的增加，System.IO.Packaging API 会默默地从内存切换到文件支持的存储，从表面上看，似乎可以实现完全相同的 MemoryStream 子类事物。
有谁知道这样的实现？我很确定框架本身没有任何内容。
问问题
11179 次
4 回答
8
程序员太努力避免使用文件。在 Windows 中，内存和文件之间的区别非常小。您用于 MemoryStream 的任何内存实际上都需要一个文件。存储由分页文件 c:\pagefile.sys 提供支持。反之亦然，您使用的任何文件都由内存支持。文件数据由文件系统缓存缓存在 RAM 中。因此，如果机器有足够的 RAM，那么如果您使用 FileStream，您实际上只会从内存读取和写入内存。并从使用内存中获得您期望的性能。它是完全免费的，您不必编写任何代码来启用它，也不必管理它。
如果机器没有足够的 RAM，那么它会以同样的方式恶化。当您使用 MemoryStream 时，分页文件开始丢弃，您将被磁盘拖慢。当您使用文件时，数据将不适合文件系统缓存，并且您将被磁盘拖慢。
你当然会得到使用文件的好处，你不会再耗尽内存。请改用 FileStream。
于 2013-07-29T13:01:05.050 回答
2
预计会发生这种情况，MemoryStream因此您应该实现自己的逻辑或使用一些外部类。这是一篇解释MemoryStream大数据问题的帖子，并且该帖子提供了替代MemoryStream MemoryStream的替代品
于 2013-07-29T10:55:14.677 回答
1
我们的团队也遇到过类似的障碍。一些评论者建议开发人员需要更好地使用文件。如果可以选择直接使用文件系统，请这样做，但这并不总是一种选择。
如果像我们需要的那样，您想在应用程序周围传递从文件中读取的数据，则不能传递 FileStream 对象，因为它可以在您完成读取数据之前被释放。我们最初求助于 MemoryStreams 让我们可以轻松地传递数据，但遇到了同样的问题。
我们使用了几种不同的解决方法来缓解这个问题。
我们使用的选项包括：
- 实现一个包装类以将数据存储在多个（因为数组仍然受限于
int.MaxValue条目数）byte[] 对象中，并公开使您几乎可以将它们视为 Stream 的方法。我们仍然不惜一切代价避免这种情况。 - 使用某种“令牌”来传递对数据位置的引用，并等待在应用程序中“及时”加载数据。
于 2020-06-25T14:54:45.100 回答
-1
我建议检查一下这个项目。
http://www.codeproject.com/Articles/348590/A-replacement-for-MemoryStream
我相信内存流的问题来自这样一个事实，即在它之下它们仍然是单个字节 [] 的精美包装器，因此仍然受到 .net 要求的约束，即即使在 64 位程序中，所有对象也必须小于 2gb。上述实现将 byte[] 分解为几个不同的 byte[]。
于 2014-07-06T19:32:21.673 回答