这问题我做图像处理时特意研究过，核心原因其实是磁盘上的图片是压缩格式，而内存中的Bitmap是未压缩的原始像素数据，两者的大小计算逻辑完全不同，再加上资源没及时释放，就会出现你说的内存暴涨甚至内存不足的情况。

1. 压缩格式 vs 原始像素数据的差异 #

磁盘上的JPG、PNG等常见图片格式都是经过压缩的（JPG是有损压缩，PNG是无损压缩），6MB是压缩后的文件大小。但当你用Bitmap.FromFile()加载图片时，.NET会把图片解码成未压缩的像素数组，每个像素占用的字节数取决于图片的位深：

• 32位ARGB（带透明度的最常见格式）：每个像素占4字节
• 24位RGB：每个像素占3字节
• 8位灰度图：每个像素占1字节

给你算个对应你场景的例子：如果你的图片是7200×7200分辨率的32位图，内存占用就是 7200×7200×4 = 207,360,000字节 ≈ 197.7MB，刚好和你看到的200MB左右的内存增长匹配——这个分辨率的JPG压缩后6MB完全合理，因为JPG对这类图片的压缩率能达到30:1甚至更高。

2. 重复加载导致内存暴涨的原因 #

你说重复加载6次内存就到1.2GB，这是因为每次调用Bitmap.FromFile()都会创建一个新的Bitmap实例，这些实例的像素数据会一直占用托管堆内存。如果没有主动释放资源（比如没调用Dispose()或者用using块），.NET的GC不会立即回收这些大对象，导致内存持续累积，最终触发内存不足错误。

解决办法 #

要避免这种情况，关键是确保Bitmap使用完毕后及时释放资源：

• 使用using语句（最推荐），它会自动在代码块结束时调用Dispose()，就算抛出异常也能保证资源释放：

  using (Bitmap nBmp = Bitmap.FromFile(sPath))
  {
      // 这里执行你的图片处理逻辑
  }
  

• 如果不能用using，记得在不再需要Bitmap时手动调用Dispose()，并将变量置为null帮助GC识别：

  Bitmap nBmp = Bitmap.FromFile(sPath);
  try
  {
      // 处理逻辑
  }
  finally
  {
      nBmp.Dispose();
      nBmp = null;
  }
  

内容的提问来源于stack exchange，提问作者tmighty