我需要在短时间内处理许多位图，并通过使用线程执行该操作。 现在，我记得处理所有这些，我没有内存泄漏。通常我的应用程序打开几个线程（我控制它们的数量 - 现在我只同时执行4个），并且每个进程一个大位图并进行一些额外的图形处理。
一切正常，直到我处理让我说 - 连续多达100位图。我的应用程序使用opendialog，所以我打开100个第一个位图然后我的应用程序自动处理它们。完成后，我打开下一批100位图等等（所以在这些批次之间有一个重要的停顿）。这很好用。应用程序一直在打开。我看到没有内存泄漏，在最后一批处理后它保持稳定，我可以处理更多。
当我在一个批次中选择更多位图时出现问题 - 超过300，所以我的应用程序处理所有这些位图而没有暂停。接近结束时我得到GDI + Out of Memory错误，我的应用程序挂起消耗1.7 GB内存。
我的猜测是系统无法在如此短的时间内释放内存（我的应用程序预留的更多）。可能吗？怎么处理这个？我不想在过程中添加一个愚蠢的延迟。我想管理它。
更新：原因很简单，App错误地编译为32位，所以只有~2GB的可用内存。虽然在应用仍然需要更多位图时，GC需要时间来释放内存，但应用程序达到了限制并挂起。
我将应用程序编译为64位，它完美无瑕。此外，我将控制内存使用情况，因此它不像现在那样无人值守。感谢所有提示和有趣的改进点！
答案 0 :(得分：1)
取决于你所说的“短时间”多长时间，你绝对可以看Memory Mapped Files。使用它们显着可以减少RAM内存压力，并且不会在速度上松动。但是，正如我先说的那样，这取决于你需要多快处理它们。
所以我肯定会建议你也看看这个选项，测量一下它是否适合你的需要。
答案 1 :(得分：1)
您的应用程序是否编译为32位进程？如果是这样，无论机器有多少RAM，您都将耗尽2Gb的内存。编译为64位将允许您充分利用所有系统内存，并且如果开始耗尽RAM将使用交换空间（这当然会减慢应用程序速度，但可能是一个比丢弃更好的解决方案记忆异常）。