很长一段时间以来,我注意到我的服务器应用程序的 Win64 版本泄漏内存。虽然 Win32 版本在内存占用相对稳定的情况下运行良好,但 64 位版本使用的内存定期增加 - 可能 20Mb/天,没有任何明显的原因(不用说,FastMM4 没有报告任何内存泄漏) . 32 位和 64 位版本的源代码相同。该应用程序是围绕 Indy TIdTCPServer 组件构建的,它是一个高度多线程的服务器,连接到数据库,用于处理由 Delphi XE2 制作的其他客户端发送的命令。
我花了很多时间检查自己的代码并试图理解为什么 64 位版本会泄漏这么多内存。我最终使用了旨在跟踪内存泄漏的 MS 工具,如 DebugDiag 和 XPerf,似乎 Delphi 64 位 RTL 中存在一个基本缺陷,每次线程与 DLL 分离时都会导致一些字节泄漏。对于必须 24/7 不间断运行且无需重新启动的高度多线程应用程序,此问题尤为重要。
我用一个非常基本的项目重现了这个问题,该项目由一个主机应用程序和一个库组成,两者都是用 XE2 构建的。DLL 与主机应用程序静态链接。宿主应用程序创建只调用虚拟导出过程并退出的线程:
这是该库的源代码:
library FooBarDLL;
uses
Windows,
System.SysUtils,
System.Classes;
{$R *.res}
function FooBarProc(): Boolean; stdcall;
begin
Result := True; //Do nothing.
end;
exports
FooBarProc;
宿主应用程序使用一个计时器来创建一个只调用导出过程的线程:
TFooThread = class (TThread)
protected
procedure Execute; override;
public
constructor Create;
end;
...
function FooBarProc(): Boolean; stdcall; external 'FooBarDll.dll';
implementation
{$R *.dfm}
procedure THostAppForm.TimerTimer(Sender: TObject);
begin
with TFooThread.Create() do
Start;
end;
{ TFooThread }
constructor TFooThread.Create;
begin
inherited Create(True);
FreeOnTerminate := True;
end;
procedure TFooThread.Execute;
begin
/// Call the exported procedure.
FooBarProc();
end;
这是一些使用 VMMap 显示泄漏的屏幕截图(查看名为“Heap”的红线)。以下屏幕截图是在 30 分钟间隔内拍摄的。
32位二进制显示增加了16个字节,这是完全可以接受的:
64位二进制显示增加了12476字节(从820K到13296K),问题比较多:
堆内存的不断增加也被 XPerf 证实:
使用 DebugDiag 我能够看到分配泄漏内存的代码路径:
LeakTrack+13529
<my dll>!Sysinit::AllocTlsBuffer+13
<my dll>!Sysinit::InitThreadTLS+2b
<my dll>!Sysinit::::GetTls+22
<my dll>!System::AllocateRaiseFrame+e
<my dll>!System::DelphiExceptionHandler+342
ntdll!RtlpExecuteHandlerForException+d
ntdll!RtlDispatchException+45a
ntdll!KiUserExceptionDispatch+2e
KERNELBASE!RaiseException+39
<my dll>!System::::RaiseAtExcept+106
<my dll>!System::::RaiseExcept+1c
<my dll>!System::ExitDll+3e
<my dll>!System::::Halt0+54
<my dll>!System::::StartLib+123
<my dll>!Sysinit::::InitLib+92
<my dll>!Smart::initialization+38
ntdll!LdrShutdownThread+155
ntdll!RtlExitUserThread+38
<my application>!System::EndThread+20
<my application>!System::Classes::ThreadProc+9a
<my application>!SystemThreadWrapper+36
kernel32!BaseThreadInitThunk+d
ntdll!RtlUserThreadStart+1d
Remy Lebeau在 Embarcadero 论坛上帮助我了解正在发生的事情:
第二次泄漏看起来更像是一个明确的错误。在线程关闭期间,正在调用 StartLib(),它调用 ExitThreadTLS() 以释放调用线程的 TLS 内存块,然后调用 Halt0() 以调用 ExitDll() 以引发由 DelphiExceptionHandler() 捕获的异常以调用 AllocateRaiseFrame( ),它在访问名为 ExceptionObjectCount 的 threadvar 变量时间接调用 GetTls() 和 InitThreadTLS()。这将重新分配仍在关闭过程中的调用线程的 TLS 内存块。因此,StartLib() 不应该在 DLL_THREAD_DETACH 期间调用 Halt0(),或者 DelphiExceptionHandler 在检测到引发 _TExitDllException 时不应该调用 AllocateRaiseFrame()。
对我来说似乎很清楚,Win64 处理线程关闭的方式存在一个重大缺陷。这种行为禁止开发任何必须在 Win64 下 27/7 运行的多线程服务器应用程序。
所以:
- 你觉得我的结论怎么样?
- 你们有没有解决这个问题的方法?