我在使用 Delphi 7 中的 WMI 查询(远程)PC 时遇到内存泄漏。内存泄漏仅发生在 Windows 2003(和 Windows XP 64)上。 Windows 2000没问题，Windows 2008也没有问题。不知道有没有人遇到过类似的问题。

泄漏仅发生在某些 Windows 版本中这一事实表明它可能是 Windows 问题，但我一直在网上搜索但未能找到解决该问题的修补程序。此外，这可能是 Delphi 问题，因为在 C# 中具有类似功能的程序似乎没有这种泄漏。后一个事实使我相信可能有另一种更好的方法来在 Delphi 中获取我需要的信息而不会发生内存泄漏。

我已经包含了一个小程序的源代码以暴露下面的内存泄漏。如果 sObject.Path_ 行低于 { 泄漏! 注释被执行，内存泄漏发生。如果我把它注释掉，就没有泄漏。 (显然，在“真实”程序中，我对 sObject.Path_ 方法调用的结果做了一些有用的事情:)。)

在我的机器上快速地对 Windows 任务管理器进行分析，我发现了以下内容:

                       Before  N=100  N=500  N=1000
With sObject.Path_     3.7M    7.9M   18.2M  31.2M
Without sObject.Path_  3.7M    5.3M    5.4M   5.3M

I guess my question is: has anyone else encountered this problem? If so, is it indeed a Windows issue, and is there a hotfix? Or (more likely) is my Delphi code broken, and is there a better way to get the information I need?

You'll notice on several occasions, nil is assigned to objects, contrary to the Delphi spirit... These are COM objects that do not inherit from TObject, and have no destructor I can call. By assigning nil to them, Windows's garbage collector cleans them up.

program ConsoleMemoryLeak;

{$APPTYPE CONSOLE}

uses
  Variants, ActiveX, WbemScripting_TLB;

const
  N = 100;
  WMIQuery = 'SELECT * FROM Win32_Process';
  Host = 'localhost';

  { Must be empty when scanning localhost }
  Username = '';
  Password = '';

procedure ProcessObjectSet(WMIObjectSet: ISWbemObjectSet);
var
  Enum: IEnumVariant;
  tempObj: OleVariant;
  Value: Cardinal;
  sObject: ISWbemObject;
begin
  Enum := (wmiObjectSet._NewEnum) as IEnumVariant;
  while (Enum.Next(1, tempObj, Value) = S_OK) do
  begin
    sObject := IUnknown(tempObj) as SWBemObject;

    { Leak! }
    sObject.Path_;

    sObject := nil;
    tempObj := Unassigned;
  end;
  Enum := nil;
end;

function ExecuteQuery: ISWbemObjectSet;
var
  Locator: ISWbemLocator;
  Services: ISWbemServices;
begin
  Locator := CoSWbemLocator.Create;
  Services := Locator.ConnectServer(Host, 'root\CIMV2',
                  Username, Password, '', '', 0, nil);
  Result := Services.ExecQuery(WMIQuery, 'WQL',
                  wbemFlagReturnImmediately and wbemFlagForwardOnly, nil);
  Services := nil;
  Locator := nil;
end;

procedure DoQuery;
var
  ObjectSet: ISWbemObjectSet;
begin
  CoInitialize(nil);
  ObjectSet := ExecuteQuery;
  ProcessObjectSet(ObjectSet);
  ObjectSet := nil;
  CoUninitialize;
end;

var
  i: Integer;
begin
  WriteLn('Press Enter to start');
  ReadLn;
  for i := 1 to N do
    DoQuery;
  WriteLn('Press Enter to end');
  ReadLn;
end.

最佳答案

我可以重现该行为，代码在 Windows XP 64 上泄漏内存，而在 Windows XP 上则不会。有趣的是，只有在读取 Path_ 属性时才会发生这种情况，使用相同的代码读取 Properties_ 或 Security_ 不会泄漏任何内存。 WMI 中特定于 Windows 版本的问题看起来是最可能的原因。我的系统是最新的 AFAIK，因此可能也没有针对此问题的修补程序。

不过，我想对您重置所有变体和接口(interface)变量发表评论。你写

You'll notice on several occasions, nil is assigned to objects, contrary to the Delphi spirit... These are COM objects that do not inherit from TObject, and have no destructor I can call. By assigning nil to them, Windows's garbage collector cleans them up.

这不是真的，因此没有必要将变量设置为 nil 和 Unassigned。 Windows 没有垃圾收集器，您正在处理的是引用计数对象，一旦引用计数达到 0，这些对象就会立即被销毁。Delphi 编译器会插入必要的调用以根据需要增加和减少引用计数。您对 nil 和 Unassigned 的赋值会减少引用计数，并在它达到 0 时释放对象。

对变量的新赋值或过程的退出也会处理此问题，因此额外的赋值(尽管没有错误)是多余的，并且会降低代码的清晰度。下面的代码是完全等价的，不会泄漏任何额外的内存:

procedure ProcessObjectSet(WMIObjectSet: ISWbemObjectSet);
var
  Enum: IEnumVariant;
  tempObj: OleVariant;
  Value: Cardinal;
  sObject: ISWbemObject;
begin
  Enum := (wmiObjectSet._NewEnum) as IEnumVariant;
  while (Enum.Next(1, tempObj, Value) = S_OK) do
  begin
    sObject := IUnknown(tempObj) as SWBemObject;
    { Leak! }
    sObject.Path_;
  end;
end;

我想说的是，只有当这确实释放了对象(因此当前引用计数必须为 1)并且销毁本身应该恰好在此时发生时，才应该显式重置接口(interface)。后者的示例是可以释放大块内存，或者需要关闭文件或释放同步对象。

关于windows - 在 Delphi 7 中使用 WMI 内存泄漏，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1044215/