delphi的 FastMM 无法检测GDI+对象内存泄漏
时间:2015-01-27 19:26 来源: 我爱IT技术网 作者:小搜
虽说FastMM相对比较好用，但它也是有不少局限的，比如不能检测动态库内存泄漏（包含调试信息的动态库可以检测）。
因为GDI+使用的是gdiplus.dll，所有对象都是动态库中创建的，而且没有包含调试信息，所以无法检查GDI+对象的内存泄漏。
这个问题着实让我头疼了一阵子，因为写代码不太注意，存在着一点内存泄露，又因为操作的图片都不小，所以运行一阵子就会耗尽虚拟内存，从而GDI+绘图的时候无法从内存堆中创建数据，因此图画出来都是黑的，这个问题在用户看来可不是小问题，测试时又很难重现，最后还是我写了一自动测试脚本才最终再连续测试了几千次后重现了这个问题。
下面介绍两个检查GDI+内存泄漏的笨办法，之所以是笨办法就是因为这办法确实很笨。
方法1：
uses
JclSysInfo;{这是jcl中的一个单元，需要先装jedi的jvcl组件包}
function getUsedVirtualMemorySize : Integer;
function _toM(const value: Integer): double;
begin
Result := value / 1024 / 1024;
end;
begin
Result := _toM(GetTotalVirtualMemory - GetFreeVirtualMemory);
end;
执行getUsedVirtualMemorySize可以获得已使用虚拟内存大小，正常情况下，这个数组应该是保持不变的，如果有内存泄漏这个数字会持续增长。
你可以写一个测试小程序，专门测试有内存泄漏的代码，弄一个循环，每次都输出getUsedVirtualMemorySize结果，就知道有没有内存泄漏了。当然了，用windows任务管理器也可以，但即使没有内存泄漏任务管理器的虚拟内存也会变化，而用getUsedVirtualMemorySize则没有这个问题，它更准确一些。
方法2：
采用代码注释的办法，结果方法1中的getUsedVirtualMemorySize使用效果更好。
具体做法就是把你怀疑内存泄漏的代码注释掉，然后通过getUsedVirtualMemorySize来观察是否有内存泄漏，逐步缩小范围，从而最终确定内存泄漏的代码。
我就是用这两个方法解决了恼人的GDI+内存泄漏问题。
因为GDI+使用的是gdiplus.dll，所有对象都是动态库中创建的，而且没有包含调试信息，所以无法检查GDI+对象的内存泄漏。
这个问题着实让我头疼了一阵子，因为写代码不太注意，存在着一点内存泄露，又因为操作的图片都不小，所以运行一阵子就会耗尽虚拟内存，从而GDI+绘图的时候无法从内存堆中创建数据，因此图画出来都是黑的，这个问题在用户看来可不是小问题，测试时又很难重现，最后还是我写了一自动测试脚本才最终再连续测试了几千次后重现了这个问题。
下面介绍两个检查GDI+内存泄漏的笨办法，之所以是笨办法就是因为这办法确实很笨。
方法1：
uses
JclSysInfo;{这是jcl中的一个单元，需要先装jedi的jvcl组件包}
function getUsedVirtualMemorySize : Integer;
function _toM(const value: Integer): double;
begin
Result := value / 1024 / 1024;
end;
begin
Result := _toM(GetTotalVirtualMemory - GetFreeVirtualMemory);
end;
执行getUsedVirtualMemorySize可以获得已使用虚拟内存大小，正常情况下，这个数组应该是保持不变的，如果有内存泄漏这个数字会持续增长。
你可以写一个测试小程序，专门测试有内存泄漏的代码，弄一个循环，每次都输出getUsedVirtualMemorySize结果，就知道有没有内存泄漏了。当然了，用windows任务管理器也可以，但即使没有内存泄漏任务管理器的虚拟内存也会变化，而用getUsedVirtualMemorySize则没有这个问题，它更准确一些。
方法2：
采用代码注释的办法，结果方法1中的getUsedVirtualMemorySize使用效果更好。
具体做法就是把你怀疑内存泄漏的代码注释掉，然后通过getUsedVirtualMemorySize来观察是否有内存泄漏，逐步缩小范围，从而最终确定内存泄漏的代码。
我就是用这两个方法解决了恼人的GDI+内存泄漏问题。
- 评论列表（网友评论仅供网友表达个人看法，并不表明本站同意其观点或证实其描述）
-