多次使用MemoryStream时遇到问题。
示例:
For Each XImage As XImage In pdfDocument.Pages(pageCount).Resources.Images
Dim imageStream As New MemoryStream()
XImage.Save(imageStream, System.Drawing.Imaging.ImageFormat.Jpeg)
' some further processing
imageStream.Close()
imageStream.Dispose()
Next
这段代码循环显示PDF文件页面上的图像。该文件最多可包含500页,每页可提供5个图像。它导致数千次迭代。问题是MemoryStream没有被释放,导致Out of Memory异常。 XImage通常大约为250 kB。
我在这里使用Aspose.PDF库来处理PDF(XImage是这个库中的一个类),但没关系。我试图做一个简单的例子,我只是创建一个新的MemoryStream并将虚拟位图保存到它。它导致了同样的问题。
我也尝试使用FileStream而不是MemoryStream,但它的行为相同。
任何帮助表示赞赏。
由于
伊日
答案 0 :(得分:20)
释放流中的内存。我答应你。真的,它是。
未释放的是以前由该内存占用的应用程序中的地址空间。您的计算机可以使用大量的ram,但是您的特定应用程序崩溃了,因为它无法在其地址表中找到位置以进行分配。
你达到极限的原因是MemoryStream随着它的增长而回收它的缓冲区。它在内部使用byte []来保存其数据,并且默认情况下将数组初始化为特定大小。在写入流时,如果超过数组大小,则流使用加倍算法来分配新数组。然后将信息从旧数组复制到新数组。在此之后,旧的数组可以并且将被收集,但它不会被压缩(想想:defragged)。结果是地址空间中的漏洞将不再使用。一个MemoryStream可能使用多个数组,导致几个内存空间的总地址空间可能比源数据大得多。
AFAIK,目前无法强制垃圾收集器压缩你的内存地址空间。因此,解决方案是分配一个可以处理最大图像的大块,然后一遍又一遍地重复使用同一个块,这样就不会得到无法访问的内存地址。
对于此代码,这意味着在循环外部创建内存流,并将整数传递给构造函数,以便将其初始化为合理的字节数。您会发现这也为您带来了不错的性能提升,因为您的应用程序突然不再花时间频繁地将数据从一个字节数组复制到另一个字节数组,这意味着即使您可以压缩地址表,这也是更好的选择:
Using imageStream As New MemoryStream(307200) 'start at 300K... gives you some breathing room for larger images
For Each XImage As XImage In pdfDocument.Pages(pageCount).Resources.Images
'reset the stream, but keep using the same memory
imageStream.Seek(0, SeekOrigin.Begin)
imageStream.SetLength(0)
XImage.Save(imageStream, System.Drawing.Imaging.ImageFormat.Jpeg)
' some further processing
Next
End Using