我们有一个相当复杂的Delphi应用程序，它使用.NET程序集。 我们使用FastMM作为内存管理器。
我们一直在遇到EOutOfMemory异常。所以我一直在研究这个问题。我们怀疑Delphi对象之间有一些循环引用。或许某些.NET对象持有对Delphi对象的引用，阻止它们被释放。
到目前为止，我还没有找到任何我们可以改变的东西，这实在令人沮丧，因为显然我们在某个地方遇到了问题。
但今天我发现了一些纯粹的机会。 当我们的应用程序启动时，任务管理器报告ca. 513 MB正在使用的内存。 我刚推出它但不得不去吃午饭。 当我回来的时候，我偶然发现应用程序现在只使用了75 MB。 奇怪我想，必须崩溃或我假设的东西。 不，完全没有，App运行得很好。 我做了什么 - ＆gt;没有。让它闲置。 我们的应用程序是一个Windows桌面应用程在处于闲置状态时，情况并不多。
所以我开始进一步研究这个问题。 它是可重复的。随着时间的推移，内存消耗开始大幅下降。 大约过后50分钟它达到了32.1 MB !!!
我监控过.NET垃圾收集器性能计数器，没有太大的变化。因此，我怀疑问题出在Delphi方面 - ＆gt;它指向FastMM。
我不是FastMM的专家。我确定并且未启用FullDebugMode。 有没有其他人经历过这样的事情？ 什么提示/想法可能在FastMM中错误配置？
万分感谢!!
答案 0 :(得分：1)
操作系统有时会识别空闲应用程序的未使用的RAM，将其释放给其他应用程序，然后在应用程序消耗的资源中不再计算它。
在这样一个混合应用程序中，大多数内存是由.Net框架保留的，对于它的垃圾收集器，我想。 GC将在空闲模式下运行，并释放/压缩其内存。可能是发生了什么。将应用中的一些日志添加到monitor the actual FastMM4 heap consumption。
可能存在内存泄漏，并且您达到了32位进程的2GB限制。尝试set the 3GB flag for the exe。或者切换到64位可执行文件 - 这将使您的.Net代码满意。运行FastMM4 in memory leak reporting mode以确保应用安全。