Delphi 内存问题 (FastMM4)答案

【问题标题】：Delphi Memory Issue (FastMM4)Delphi 内存问题 (FastMM4)
【发布时间】：2011-09-29 16:07:58
【问题描述】：

从事一个使用工厂构造对象的项目。我将指向工厂函数的指针全局保存在 vars 中（我知道这很糟糕），并在初始化时注册它们。

我最近很想看看该项目是否存在内存泄漏，因此决定下载 FastMM4 并查看一下。它提出了一些我可以修复的错误，但我有点难过似乎我没有释放与工厂相关的内存，如下面的代码所示，我遇到了一个小的内存泄漏。不荒谬但令人讨厌。

我会用什么来释放内存（如果是的话）我试过 dispose(@factoryfunction) 但似乎破坏了一切。我不太擅长低级指针的东西总是让我很困惑，所以如果有人能提供帮助那就太好了。

我在下面包含了一个示例，我刚刚从头顶写下了它，说明了我遇到的问题。

干杯，

巴里

unit Test;

interface

uses classes;

type

TAFactoryFunction = reference to function (const aType : integer): TObject;

function testfunction (const aType : integer) : TObject;

implementation

function testfunction(const aType: integer) : TObject;
begin
    result := TObject.Create;
end;

var
   FactoryFunction : TAFactoryFunction

initialization
   FactoryFunction := testfunction;

finalization
   // possibly some freemem code here?

end.

【问题讨论】：

我很好奇 - 你为什么使用“函数引用”而不是简单的函数类型？这将避免内存泄漏，因为它不会涉及编译器跳过箍来实现可以更简单地实现的目标。或者这是简化示例不能完全反映原始场景的情况之一？
就像使用它的打字相对松散一样，因此变量可以采用过程、方法或匿名方法。它被用于框架，因此希望使其尽可能可扩展。
我不确定这是否能实现，不是吗？引用仍然必须是适当签名的函数，不是吗？如果不是，那么我会说这是避免瘟疫之类的事情的一个理由！如果我将一个类型声明为具有特定签名的函数，那么它最好这样使用。其他任何事情都需要令人头疼的维护（更不用说混乱了）。问题仍然存在，您为什么要允许这种灵活性，而不是因为您可以/想要？灵活性在您的框架中的用途是什么？

标签： delphi memory-leaks global-variables factory fastmm

【解决方案1】：

我刚刚在 Delphi 2010 中对此进行了测试，它似乎是一个错误。编译器应该生成代码来清理它，但事实并非如此。正如大卫建议的那样，即使写 FactoryFunction := nil 也行不通。

您应该在 QC 中将此报告为错误。

【讨论】：

似乎对IntfCopy 的额外调用导致引用计数设置为2。不知道为什么会这样。