我的程序永远不会释放内存。为什么?

任务管理器不是检测内存泄漏的正确工具。Delphi会分配大块内存,并将其保留以备将来使用,因此即使在释放所有资源后,分配的内存也会有一定的增加。任何其他结果(以及更详细的答案)都只能通过使用专门的内存分析工具来获得。AQTime是第一个想到的,或者如果你能找到旧的但有用的MemProof,它会对你有很大帮助(MemProof是免费的,对于内存分析来说,它比AQTime更方便)。

FastMM很可能在应用程序终止时不会显示内存泄漏(例如,因为所有对象都是所拥有的TComponent,而所有者会释放它们)。
但与此同时,在运行这些组件时,这些组件可能仍然存在,并且不会很快释放。

您是否使用了显示当前内存使用情况的窗体的FastMM单元?

<编辑>
这是 FastMMUsageTracker.pas 在目录中 ...\FastMM\Demos\Usage Tracker 。
使用该单元,然后调用 ShowFastMMUsageTracker 功能。 你可以每隔一段时间刷新一次该表单,看看你的内存消耗是如何增长的。 我放了一个 FastMMUsageTrackerProject 样品 on-line ,包括FastMM4的更新,使其更容易检查和调试内存泄漏:

• 中的表单 FastMMUsageTracker 单元现在可以调整大小,其中的控件以正确的方式定位
• 有一个新的 FastMmBootstrapUnit 使调试特定内存泄漏更容易的单元

上周我手头有一个第三方DLL,它不是用Delphi编写的。
DLL使用Windows GlobalAlloc调用发生内存泄漏,FastMM未跟踪这些调用。

注意:我即将在上发布FastMM的更新

--jeroen

答案:

我刚刚从我的项目中删除了FastMM,在释放了所有这些子窗口后,程序返回到了几个MB。许多人可能会争辩说,这不是一种不当行为,FastMM这样做是为了进行某种古怪的内存优化。它们可能是真的。然而,它可能对我的应用程序有好处,但对其他正在运行的应用程序可能没有好处。

所以,至少我们知道是谁造成了这种情况。我担心了一整天,可能程序正在像一个旧水桶一样泄漏RAM。我现在松了一口气。

更新:

为了确认这种行为是由FastMM生成的(正如Barry Kelly所建议的),我创建了第二个程序,该程序分配了大量RAM。一旦Windows的RAM用完,我的程序内存利用率就恢复到原来的值。
(注意:我并不是说FastMM有漏洞!)

我的程序没有泄漏。问题解决了。

FastMM的内存泄漏跟踪的主要限制是它只能在关闭程序时运行。这可能是因为你仍然持有对对象或其他数据的引用,这些数据在你关闭程序时会被清除,但在那之前一直存在。

例如,当您关闭MDI子窗口时,是对它们调用“自由”或“释放”,还是只是让它们消失?如果它们被隐藏但没有被释放,它们仍将留在记忆中。

如果关闭MDI窗体,它不会自动释放。使用Action=caFree(谷歌搜索)来确保表单也被释放。