我们有一个相当复杂的delphi应用程序，它使用.NET组件。我们使用FastMM作为我们的内存管理器。
我们一直遇到Eoutofmemory例外。所以我已经对此进行了一段时间的调查。我们怀疑我们在Delphi对象之间有一些循环引用。或者也许有一些.NET对象将引用对Delphi对象，从而阻止它们被释放。
到目前为止，我还没有找到任何可以改变目的的东西，这确实令人沮丧，因为显然我们在某个地方有问题。
，但是今天我发现了一些东西。当我们的应用启动任务管理器报告时。使用513 MB内存。我刚刚推出了它，但必须离开午餐。当我回来时，我注意到该应用程序现在仅使用75 MB。奇怪的是，我认为，一定已经崩溃了或我假设的事情。不，根本不是，应用程序运行完美。我做了什么 ->什么也没有。只要让它闲置。我们的应用程序是Windows桌面应用程序。在闲置状态时，没有太多事情发生。
所以我开始进一步研究。它是可重现的。随着时间的流逝，内存消耗开始减少。大约之后。50分钟达到32.1 MB !!!
我已经监视了.NET垃圾收集器性能计数器，但没有很大的变化。因此，我怀疑问题在Delphi侧 ->指向Fastmm。
我不是FastMM的专家。我确保未启用fulldebugmode。还有其他人经历过这样的事情吗？有什么提示/想法在fastmm中可能被错误配置吗？
感谢一百万！
-
该操作系统有时会标识无用的闲置应用程序，以将其释放到其他应用程序中，然后在应用程序消费的资源中不再计算它。
-
在这样的混合应用中，我猜是由.NET框架保留的大多数内存是为其垃圾收集器保留的。GC将在空闲模式下运行，并免费/紧凑其内存。可能是发生的事情。在应用程序中添加一些日志以监视实际的fastmm4堆消耗。
-
可能存在内存泄漏，您达到了32位过程的2GB限制。尝试为EXE设置3GB标志。或切换到64位可执行文件 - 这将使您的.NET代码快乐。在内存泄漏报告模式中运行fastmm4，以确保应用程序安全。