由于看似过早的 Out of Memory 异常，我们一直在仔细检查各种 .NET 结构的内存使用情况……尤其是大对象，它们往往会使大对象堆碎片化，从而导致过早的 Out of Memory 异常。一个有点令人惊讶的领域是 .NET Image 类：Bitmap 和 Metafile。
以下是我们认为我们已经学到的东西，但无法找到 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) 因此，似乎有四个独立的内存块被单独管理，每个内存块用完都会导致相同的内存不足异常：小对象堆（托管对象 < 85KB，由 GC 压缩），大对象堆（由 GC 收集的 > 85KB 的托管对象，但未压缩）、本机内存（非托管对象，可能未压缩）和桌面堆（管理窗口句柄和此类有限资源）。我是否正确记录了这四个？还有其他我们应该注意的吗？
任何人都可以就上述内容提供的任何清晰度将不胜感激。如果有很好的书或文章可以充分解释上述内容，请告诉我。（我很高兴完成必读；但绝大多数书籍都没有那么深，因此不要告诉我任何我不知道的事情。）
谢谢！
