.NET 图像类的内存使用和碎片：位图与元文件答案

【问题标题】：The Memory Usage and Fragmentation of .NET Image classes: Bitmap vs. Metafile.NET 图像类的内存使用和碎片：位图与元文件
【发布时间】：2013-03-20 16:54:26
【问题描述】：

由于看似过早的 Out of Memory 异常，我们一直在仔细检查各种 .NET 结构的内存使用情况……尤其是大型对象，它们往往会使大型对象堆碎片化，从而导致过早的 Out of Memory 异常。一个有点令人惊讶的领域是 .NET 图像类：位图和元文件。

以下是我们认为我们已经了解的内容，但无法找到 MS 文档进行验证，因此如果其他人可以提供任何确认，我们将不胜感激：

(1) 当您从压缩的光栅文件（JPG、PNG、GIF 等）创建位图对象时，它会在该文件的全分辨率下为完全未压缩的像素阵列消耗内存。因此，例如，一个 9000x3000 像素的 5MB JPG 将被扩展为 9000x3000x3 字节（假设 24 位颜色，无 alpha），或消耗 81MB 内存。对吗？

(1a) 有一些证据（参见下面的 2b）表明它还存储原始压缩格式……因此，在这种情况下实际上是 86MB。但这还不清楚……有人知道吗？

(2) 当您创建一个 Metafile 对象，然后在其中绘制一个光栅文件（JPG、PNG、GIF 等）时，它只会消耗压缩文件的内存。因此，如果您将 9000x3000 像素的 5MB JPG 绘制到 Metafile 中，它只会消耗大约 5MB 的内存。对吗？

(2a) 要将光栅文件绘制到 Metafile 对象中，唯一的方法似乎是使用文件加载 Bitmap，然后将 Bitmap 绘制到 Metafile 中。有没有更好的方法不涉及临时加载庞大的位图数据（并导致相关的内存碎片）？

(2b) 当您将位图绘制到元文件中时，它使用大小类似于原始压缩文件的压缩格式。它是否通过将原始压缩文件存储在位图中来做到这一点？还是通过使用原始压缩设置重新压缩展开的位图来做到这一点？

(3) 我们最初假设大 (>85KB) 图像对象将被放置在大对象堆中。事实上，情况似乎并非如此。相反，每个位图和每个元文件都是小对象堆中的一个 24 字节对象，它指的是包含真实数据的本机内存块。对吗？

(3a) 我们假设这样的 Native Memory 就像 Large Object Heap 一样，不能被压缩……一旦大对象放入 Native Memory，它就永远不会被移动，因此 Native Memory 的碎片会导致大对象堆的碎片化问题很多。真的？或者是否对底层位图/元文件数据进行特殊处理更有效？

(3b) 因此，似乎有四个独立的内存块分别管理，每个内存块用完都会导致相同的内存不足异常：小对象堆（托管对象

任何人都可以就上述内容提供的任何清晰度将不胜感激。如果有很好的书或文章可以充分解释上述内容，请告诉我。（我很高兴完成必读；但绝大多数书籍都没有那么深，因此不要告诉我任何我不知道的东西。）

谢谢！

【问题讨论】：

GDI+ 将图像数据存储在非托管内存中。所以你的假设都不接近。忘记处理位图是一种快速解决 OOM 的方法。地址空间碎片是另一种情况，一个 32 位进程在一段时间后达到 90 MB 作为危险区域。
“你的假设都不接近”？？但是你所说的一切都与我上面的假设一致......所以，不确定你在告诉我什么。您是说“本机内存”与“非托管内存”不同吗？还是您的意思是“您的所有假设都很接近”？？
在 2(a) 上，到目前为止我想出的最好的结果是“不，但是是的排序...”：创建一个单独的 .exe，它只是将任何给定的光栅文件读入一个Bitmap 然后在磁盘上打开一个新的 Metafile 文件并将该 Bitmap 的 DrawImage 放入该 Metafile 并退出。然后在我的主应用程序中，当用户将我指向一个光栅文件，而不是在我的主应用程序中打开它并生成内存碎片时，我调用该 .exe 来创建一个包含元文件的临时文件，然后在我的主应用程序中我将该文件直接读入元文件。笨重，但对我的主应用程序没有内存影响。有更好的想法吗？

标签： .net image memory

【解决方案1】：

有两种存储图像数据的方法：像素或向量。 Bitmap 是关于像素的，Metafile 是关于像素和向量的。矢量数据的存储效率要高得多。

为了允许对位图进行操作，它们的数据必须未压缩地存储在内存中。否则GetPixel 和SetPixel 将不得不为每次更改解压缩、更改、重新压缩位图（如果这甚至可以开始的话）。

Metafiles 由 Microsoft 创建，旨在与 GDI 一起使用，因此它可能包含一些内存效率更高的压缩算法，可直接与显卡一起使用。此外，没有用于元文件的 GetPixel SetPixel 方法，因此不必在内存中解压缩即可进行操作。

您不必关心运行时使用的内存池。还有更多，运行时决定它放置对象的位置。此外，您不应该关心可能可能因使用（大）对象而引起的内存不足异常。运行时将尽其所能（将对象放在其他对象之间的间隙中，压缩堆，扩展可用的虚拟内存）以确保您不会遇到内存不足的异常。如果您确实遇到了这样的异常，那么您的代码中可能还有另一个问题需要修复（例如内存泄漏）。

内存堆、映射和表的概述：(source)

此外，您关于将超过 85 KiB 的对象放置在大对象堆上的假设并不完全正确。对于当前版本的 CLR 中的 大多数 对象是正确的，但例如，在大型对象堆上也分配了一个 8 KiB 的双精度数组（1000 个双精度）。让运行时自己关心这个。

【讨论】：

不幸的是，“让运行时自己关心这个”只适用于小对象堆。我们正在使用内存分析器......我们没有泄漏......但是我们可以用完 2GB 的内存来管理不应超过大约 10MB 数据的单个文档。如何？碎片化。重新设计以最大程度地减少碎片使我们达到了 50MB……然后达到 100MB……我们正在继续努力。因此，不幸的是，由于碎片化，我们必须关注这一点。（感谢您提供该图片的源链接……那里的信息非常好。）
@BrianKennedy 我不知道你在做什么，但你有一些选择。处理完图像后立即释放图像（将所有指针清空，要求 GC 收集内存）。您可以使用 C++/CLI 自己管理图像的内存。您可以查看仅加载您需要操作的图像部分的方法，或者以压缩格式加载图像并执行您想要的操作（显示它或其他内容）的方法。
是的，Virtlink，看来我可以使用 Metafile 而不是 Bitmap 来避免未压缩的图像。不幸的是，似乎将 JPG 放入元文件的唯一方法是通过位图......虽然我可以立即处理它以释放该内存，但它仍然会导致内存碎片（似乎）。因此，我提出了上述问题。

【解决方案2】：

我知道其中一些问题的答案：

(1) 是的，这就是Bitmap图像的定义。

(3) 是的，这就是 Bitmap 实现 IDisposable 接口的原因。

(3a) 这似乎令人惊讶。处理完 Bitmap 对象后，您是否正在对它们运行 Dispose() 方法？

(3b) 至少那四个，是的。

【讨论】：

这绝对是首先要检查的，例如看this post
是的，我们的 Image 对象被正确处理。我们正在运行内存分析器...没有泄漏。