Delphi 内存管理及 FastMM 研究.docVIP

Delphi7 内存管理及 FastMM 研究Delphi缺省的共享内存管理器是BORLNDMM.DLL，这个内存管理器并不可靠，也常常出现问题，并且，在程序发布的时候必须连同这个DLL一起发布。而FastMM的共享内存管理器功能不需要DLL支持，并且更加可靠。 第三个原因是FastMM还拥有一些帮助程序开发的辅助功能，如内存泄漏检测功能，可以检测程序是否存在未正确释放的内存等。 出现什么问题 如果我们开发的应用程序，只有一个exe模块，那么，使用FastMM是一件非常简单的事情，只需要把FastMM.pas（最新版是FastMM4.pas）作为工程文件的第一个uses单元即可，如： 但是，通常情况下，我们的应用程序都是由一个exe模块加上多个dll组成的，这样，当我们跨模块传递动态内存变量如string变量时，就会出问题，比如，下面的测试程序由一个exe和一个dll组成：   当第二次执行btnDoClick过程时，就会出现内存错误，为什么这样？delphi的字符串是带引用计数的，跟接口变量一样，一旦这个引用计数为0，则会自动释放内存。在btnDoClick过程中，调用GetStr过程，用SetLength给S分配了一段内存，此时这个字符串的引用计数为1，然后执行edt1.Text := S语句，字符串的引用计数为2，循环再调用GetStr给S重新分配内存，这样原来的字符串的引用计数减1，再执行edt1.Text := S，原来的字符串引用计数为0，这时，就会被释放（注意，是在TestPrj.exe释放，而不是在Test.dll释放），但这时没有出错，当循环执行完毕之后，还有一个字符串的引用计数为2，但是执行SetLength(S, 0)之后，该字符串被edt1.Text引用，的引用计数为1，第二次执行btnDoClick时，执行edt1.Text := S时，上次的引用计数为1的字符串引用计数减一变为0，就会被释放，此时，会出现内存错误。 由此，可以看到，在另一个模块释放别的模块分配的内存，并不一定马上出现内存错误，但是，如果频繁执行，则会出现内存错误，这种不确定的错误带有很大的隐蔽性，常常在调试时不出现，但实际应用时出现，不仔细分析很难找到原因。 要解决这个问题，就要从根源找起，这个根源就是内存管理。 Delphi的内存管理 Delphi应用程序可以使用的有三种内存区：全局内存区、堆、栈，全局内存区存储全局变量、栈用来传递参数以及返回值，以及函数内的临时变量，这两种都是由编译器自动管理，而如字符串、对象、动态数组等都是从堆中分配的，内存管理就是指对堆内存管理，即从堆中分配内存和释放从堆中分配的内存（以下称内存的分配和释放）。 我们知道，一个进程只有一个栈，因此，也很容易误以为一个进程也只有一个堆，但实际上，一个进程除了拥有一个系统分配的默认堆（默认大小1MB），还可以创建多个用户堆，每个堆都有自己的句柄，delphi的内存管理所管理的正是自行创建的堆，delphi还把一个堆以链表的形式分成多个大小不等的块，实际的内存操作都是在这些块上。 delphi把内存管理定义为内存的分配（Get）、释放（Free）和重新分配（Realloc）。内存管理器也就是这三种实现的一个组合，delphi在system单元中定义了这个内存管理器TMemoryManager： 由此知道，delphi的内存管理器就是一个 TMemoryManager 记录对象，该记录有三个域，分别指向内存的分配、释放和重新分配例程。 System单元还定义了一个变量 MemoryManager ： 该变量是delphi程序的内存管理器，缺省情况下，这个内存管理器的三个域分别指向GETMEM.INC中实现的SysGetMem、SysFreeMem、SysReallocMem。这个内存管理器变量只在system.pas中可见，但是system单元提供了三个可以访问该变量的例程：  共享内存管理器 什么是共享内存管理器？ 所谓共享内存管理器，就是一个应用程序的所有的模块，不管是exe还是dll，都使用同一个内存管理器来管理内存，这样，内存的分配和释放都是同一个内存管理器完成的，就不会出现内存错误的问题。 那么如何共享内存管理器呢？ 由上分析，我们可以知道，既然要使用同一个内存管理器，那么干脆就创建一个独立的内存管理器模块（dll），其他的所有模块都使用这个模块的内存管理器来分配和释放内存。Delphi7默认就是采取这种方法，当我们使用向导创建一个dll工程时，工程文件会有这样一段话： {Important note about DLL memory management: ShareMem must be the first unit in your libr