【发布时间】:2014-05-14 04:29:32
【问题描述】:
我有以下 Delphi 代码,在一些 Windows 服务中运行:
if FindFirst(path,faArchive,searchrecord) then
try
DoSomething(searchrecord);
while FindNext(searchrecord) do
DoSomething(searchrecord);
finally
FindClose(searchRecord);
end;
这实际上是在一个线程内每 n' 秒运行一次(搜索目录内容,然后为在 .. 中找到的每个文件发送邮件,然后新内容将被另一个进程放入该文件夹中 .. 然后再次 .. )。
一切都很好(邮件已发送,文件移动到另一个文件夹等),但我们的客户抱怨内存消耗巨大......快速增加。
所以我们检查一下,首先在确认内存泄漏时,然后毫无疑问地识别该代码块 .. FindeFirst -> FindNext -> FindClose .. , 是'罪犯'
然后搜索和搜索(首先,这个..然后是网络),我们找到了“神秘”
SetProcessWorkingSetSize(GetCurrentProcess(), DWORD(-1), DWORD(-1))
观看 here、here .. 和许多其他 stackoverflow 条目,讨论使用此 Windows 功能的好处或不便。
最后一个事实是,当执行该代码块时,内存使用量似乎越来越大(FindFirst .. FindClose).. 在 Windows 任务管理器中观察这种消耗
所以..亲爱的伙伴..
- 为什么会这样? (这是一些正常的行为,一些错误..)
- 什么是“解决方案”? (有什么要“解决”的吗?..
SetProcessWorkingSetSize(GetCurrentProcess(), DWORD(-1), DWORD(-1))适合这种情况吗?.. 那么如何使用它?
【问题讨论】:
-
“DoSomething”有什么作用? (它也在该循环的范围内,并且可能是泄漏源。)您还提供了没有任何周围上下文的循环,或者表明您如何将 FindFirst 和朋友识别为泄漏源。你如何确定他们是“毫无疑问”的罪魁祸首?
-
您需要做更多的工作来识别泄漏。您使用什么诊断工具?
-
SetProcessWorkingSetSize(..., -1, -1) 只是将尽可能多的页面推出交换文件。它将实现的只是使您的应用程序的性能变得更糟。如果有泄漏,您还没有确定您的泄漏。第 1 步是使用 fastmm 完整调试。
-
你能显示真实的代码吗? (FindFirst 和 FindNext 是整数,不是布尔函数)
-
显示真实代码。其他都是猜测。
标签: delphi memory-leaks