posts - 230,  comments - 526,  trackbacks - 0

    作为一个服务器端的应用,最基本的要求就是稳定,当然要做一个稳定的服务器端,需要涉及到很多方面,

内存泄露就是稳定的一个致命杀手,因为服务器的物理内存是有限的,即使一个功能有很小的内存泄露,经过

长时间的运行,也会累积成一个非常大的内存泄露,导致服务器内存耗尽,系统崩溃。因此珍惜服务器资源是

开发者必须重视的(当然了,对于内存无法管理的语言及框架,那就算了)。

   最新版的kbmmw 中加入了内存调试功能,这个功能不但可以应用在kbmmw 服务器中,你也可以在其他程序中

使用。

  其实自从delphi 2007 开始,delphi 就默认使用FastMM 作为内存管理器,FastMM 也自带了内存泄露报告功能。

但是FastMM只能追踪通过GetMem 分配的内存资源,无法追踪windows其他方式分配的内存(Virtual/Heap/Global/Local).

 另外,即使你屏蔽了FastMM 的内存泄露报告,kbmmw 的内存调试器可以在应用中的任何时间来记录内存的使用情况。

我们要使用kbmmw 的内存调试功能,先做一下准备工作。

首先我们要打开 kbmmwconfig.inc 加入


{$DEFINE KBMMW_SUPPORT_DEBUGMEMORY}
{$DEFINE KBMMW_INSTALL_DEBUGMEMORY_HANDLERS}

这两句条件编译,以便激活kbmmw 的内存调试功能,默认是关闭的,如图。

如果没有 {$DEFINE KBMMW_SUPPORT_DEBUGMEMORY} 这一句,内存调试不起作用。

如果没有 {$DEFINE KBMMW_INSTALL_DEBUGMEMORY_HANDLERS},内存追踪不起作用。

 

现在就可以在你的程序里面 加入kbmMWDebugMemory 单元了,你的程序就有了内存调试功能了。

 

kbmmw 自动的勾住了 delphi 程序中所有的内存分配功能,包括以前的borlandMM, 和windows 自己的Virtualxxx, Globalxxx,

Localxxx and Heapxxx 这些函数。当然了,也完美支持Fastmm 的内存管理器。

kbmmw 为每次的内存分配和内存再分配都用一个唯一的自增64位 数来标记。通过这个数字,我们可以追踪在某个时间段中内存分配

的情况,这些点叫checkpoints.原理上,一个checkpoint 就是一个64位的数字,通过这些数字我们可以追踪每次的内存分配情况。

kbmmw 同时维护着一个分配的内存及分配次数的统计表。你可以任何时候来查阅这个统计表

 

procedure TForm1.Timer1Timer(Sender: TObject);
begin
     lLiveAllocationsCount.Caption:=inttostr(TkbmMWDebugMemory.LiveAllocationCount)+' ('+inttostr(TkbmMWDebugMemory.LiveAllocationCountPerSec)+'/sec)';
     lLiveAllocSize.Caption:=inttostr(TkbmMWDebugMemory.LiveAllocationSize)+' ('+inttostr(TkbmMWDebugMemory.LiveAllocationSizePerSec)+'/sec)';
     lMaxAllocationCount.Caption:=inttostr(TkbmMWDebugMemory.MaxAllocationCount);
     lMaxAllocationSize.Caption:=inttostr(TkbmMWDebugMemory.MaxAllocationSize);
     lMaxCapacity.Caption:=inttostr(TkbmMWDebugMemory.CurrentAllocationCountCapacity);
     lCheckPoint.Caption:=inttostr(FCheckPoint);
     lGCCount.Caption:=inttostr(TkbmMWDebugMemory.AllocationKeys.GCCount);
end;

 

 其中:

   LiveAllocationCount 是当然使用的、活动着的内存。它包括所有的 (Borland- object/string/memory, Localmemory, Globalmemory, Virtualmemory, Heapmemory).

  其它参数的作用请参考kbmmw 的源代码(没有源代码?那就买一份呗)。

知道了内存分配情况,那么接下来就是如何在程序结束后检测内存泄露了。

什么时候内存泄露?

就是被分配的内存,永远没有被释放。

有些内存泄露无所谓,因为其在整个应用过程中只发生一次,有点像定义了一个全局变量,这种泄漏时是可预测的,而且不随时间的增长而增长,这类泄露在delphi

的RTL 和VCL 中有很多,我们无法消灭它们,也没必要消灭它们(对于爱干、鱼儿的这些强迫症患者简直就是噩梦)。

对于那些每次执行都发生的内存泄露,随着时间的增长越来越多,耗尽系统资源,到最后导致系统崩溃。因此这种泄露我们必须消灭。

因为内存追踪无法了解一个人(我不是指“竹子”)的想法,因此在程序运行过程中,无法确定一块主动分配的内存是否真的需要释放?因此只有在程序退出时,

我们才能知道这些内存确实需要释放,然而并没有释放。所以只有在程序退出时,才能确定内存是否泄漏?

在kbmmw 里面,我们可以在尽可能早的地方把内存检测加入。

TkbmMWDebugMemory.ReportDestination('c:\temp\leaks.txt'); 
TkbmMWDebugMemory.ReportLeaksOnShutdown:=true; 
TkbmMWDebugMemory.StartLeakChecking; 

我们可以做一个明显的泄漏,测试一下

procedure TForm1.Button8Click(Sender: TObject);
var
   sl:Tstringlist;
begin

  sl:=Tstringlist.Create;
end;

运行程序,执行以上代码,然后退出。

就会显示以下提示:

如果我们去看leaks.txt

就会很明显的发现这个问题。

以上信息有时很精确,有时不一定准确,主要依靠你程序编译时的一些设置,尤其是优化代码很厉害的话,会差异很大。

当然了,内存使用情况和调试涉及的东西很多,如果你要进一步深入的话,可以看kbmmw 的源码和例子。

 

有一点需要说明,以上所有的操作都是有代价的,如果在正式生产环境中使用,尽量不要启用内存调试功能。

只有出现内存泄露时,才建议使用以上功能发现泄露原因,消灭掉泄漏后,立即关闭调试功能。

 

----------------

本来以为完了,鱼儿和竹子追着问如何知道出现发生泄漏的源代码行号,其实kbmmw 里面完全可以实现。

只是需要在编译时增加相关的调试信息。因为没有足够的调试信息,神仙也不知道是源代码的哪一行发生泄露了。

请如图设置。

 

同时,我们在程序里面需要增加相应的处理代码

procedure TForm1.FormCreate(Sender: TObject);
begin

      TkbmMWDebugStackTrace.Initialize;
     TkbmMWDebugMemory.ReportDestination('c:\temp\leaks.txt');
     TkbmMWDebugMemory.ReportLeaksOnShutdown:=true;
      TkbmMWDebugMemory.CollectStacks:=True;
     TkbmMWDebugMemory.StartLeakChecking;
     FCheckPoint:=TkbmMWDebugMemory.CheckPoint;


end;

 

这样再运行。

先记住我们故意出泄露的地方。

 

再看看泄露文件

 

现在可以消停了吧。

 

posted on 2016-06-04 14:23 xalion 阅读(...) 评论(...) 编辑 收藏