运行 x86 .NET 应用程序的 Windows 7 x64 将抛出内存不足，除非我执行 GC.Collect

Question

我已经找到了解决方案，但这种行为非常令人担忧，我想在这里询问其他人是否也看到了它。

基本上，在 x64 Windows 7 中运行的固定在 x86 中构建的相同二进制文件（将在下面解释原因）将会泄漏，除非我强制执行 GC.Collect()

解释：

1. 应用程序执行大量位图渲染（> 60 每秒）
2. 有一个外部 C++ dll（托管 C++）
3. 有两个线程（工作线程和 ui）
4. 有 UI 刷新（统计）
5. 此行为仅发生在本机上，Windows 7 x86 运行良好。

应用程序将增长到超过 1.5G，并最终抛出内存不足异常。 (1) 工作得越快，异常就越快。

对于那些准备拍摄 (2) 导致泄漏的人，我确实测试了将其删除，并且泄漏仍然存在加上，如果我执行 GC.Collect()，内存会得到很好的释放，在我的书中，这是一个.NET 问题。

谢谢。

Answer 1

好吧，为了值得，这是我的收获。

我已经看到与您遇到的问题完全相同。它回到了.NET 2.0，但我正在处理大图像，尽管我会处理图像，但内存消耗会增加 - 直到我手动调用GC.Collect()代码>.

还有什么类似的？主持！我的应用程序是一个非托管 EXE，它将使用 COM 创建一个对象，该对象是暴露给 COM 的 .NET 类。这将导致非托管 EXE 托管 CLR。

在 Windows X64 上，X32 应用程序将以 WOW（windows on windows）模式加载，这是一种类似的托管，我相信它可以表现出类似的问题。似乎 GC 无法完全了解托管环境中的内存消耗情况。

Answer 2

您是否正确处理位图以及所有其他一次性资源（包括 GDI+ 对象）？

using(Bitmap bitmap = ...)
{
    ... do your stuff
}

您需要查看您的应用程序才能找到问题 - 显然 1.5GB 对于 32 位应用程序来说是过多的。事实上，您在具有不同操作系统的不同计算机上获得不同的行为并不意味着您应该责怪操作系统。

Answer 3

您可以尝试不要过多依赖垃圾收集器。如果您重写绘制代码以清理未使用的资源，您可能不会遇到所描述的情况。

Image.Dispose()

注意 请务必先致电 Dispose
发布您对
图像。不然资源就这样了
使用不会被释放，直到
垃圾收集器调用 Image
对象的 Finalize 方法。

Answer 4

当您停止使用位图时，您必须对其进行 .Dispose() 处理。
即使您没有显式调用 .Dispose()，GC 最终也会收集这些内存（当它运行终结器时） - 但 GC 并不是过度分配内存的灵丹妙药，如果您做得更快，那么 GC 就可以使用 GC 无法直接控制的资源（非托管资源正是如此）来收集它们 - 那么 GC 机制就无法帮助您。

通过调用 GC.Collect(0)，您将强制 GC 处理对象树并调用所有终结器，如果您不调用它，那么 GC 会在它认为时间到的时候运行，到那时就为时已晚了（由于高分配率）。