作为一个服务器端的应用，最基本的要求就是稳定，当然要做一个稳定的服务器端，需要涉及到很多方面，
内存泄露就是稳定的一个致命杀手，因为服务器的物理内存是有限的，即使一个功能有很小的内存泄露，经过
长时间的运行，也会累积成一个非常大的内存泄露，导致服务器内存耗尽，系统崩溃。因此珍惜服务器资源是
开发者必须重视的（当然了，对于内存无法管理的语言及框架，那就算了）。
最新版的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;
这样再运行。
先记住我们故意出泄露的地方。
再看看泄露文件
现在可以消停了吧。
