简介FastMM4 4.97 版内存管理库源码包面向使用 Delphi 与 C Builder 进行开发的程序员尤其是需要排查内存泄漏、双重释放、越界访问等疑难问题的中高级开发者。压缩包共 89 个文件约 799KB以 pas 单元、dll 动态库、dpr/dproj 工程文件、dfm 窗体、cpp 与 def 等为主另含 res 资源、inc 配置、txt 说明及多语言翻译文件覆盖 Delphi 各版本与 BCB5/6、CB2006/2007 的替换方案。资源提供可直接替换 BorlndMM 的完整源码与预编译 FullDebugMode 组件支持线程安全分配、自定义内存策略与详细错误报告并附带使用追踪、动态加载 DLL 等示例工程便于快速集成到现有项目并定位内存缺陷。目前已有 275 人学习下载适合希望提升代码稳定性与调试效率的 Pascal 开发者参考。1. FastMM4 在 Delphi 项目里到底解决了什么问题如果你维护过一个跑了七八年的 Delphi 老项目大概率见过这种场面程序刚启动时内存占用 80MB运行三天后涨到 1.2GB任务管理器里那个进程像吹气球一样膨胀重启一下又恢复正常。客户投诉、运维甩锅、你打开代码一看满屏都是GetMem、FreeMem、TObject.Create根本不知道哪一行漏了释放。FastMM497.zip 这个包名里的 FastMM4就是冲这类问题来的——它是 Delphi 生态里最经典的内存分配器替换方案把 IDE 自带的默认内存管理器换成一套更激进、更可观测、更能抓泄漏的实现。FastMM4 的核心价值有三个第一分配和释放速度比 Delphi 原生内存管理器快尤其在多线程频繁申请小对象的场景下差距明显第二它能在编译期打开 FullDebugMode把每一次内存分配的调用栈、大小、线程 ID 全部记录下来泄漏报告直接告诉你「这块内存是在哪个单元哪一行申请的」第三它支持内存越界检测、双重释放检测、野指针检测很多在 Release 下偶发崩溃、在 Debug 下又复现不了的玄学问题挂上 FastMM4 的调试模式跑一遍就能现形。适合谁用适合还在维护 Delphi 7 到 Delphi 12 项目、被内存泄漏和偶发崩溃折磨、又不想大改业务代码的团队。替换成本极低通常只需要改一个单元引用和几行条件编译指令。2. 把 FastMM4 接进现有 Delphi 工程的最小改动路径2.1 为什么是替换内存管理器而不是重写业务代码Delphi 的内存管理是「可插拔」的System单元里有一个全局的MemoryManager记录里面是一组函数指针负责GetMem、FreeMem、ReallocMem这些底层操作。默认情况下这个记录指向 Delphi 自带的实现。FastMM4 做的事情就是在程序启动最早的时刻把这个记录替换成自己的实现。这意味着你不需要改任何业务代码里的TObject.Create或SetLength所有走 RTL 的内存操作都会自动经过 FastMM4。常见做法是在项目文件.dpr的第一行uses里加上FastMM4并且确保它排在Forms之前。因为FastMM4单元在initialization段会执行替换逻辑越早加载越好。如果你用的是 Delphi 2006 以后的版本还需要在项目选项里关掉「Use debug DCUs」之外的干扰项避免 IDE 自带的调试内存管理器抢先接管。2.2 项目文件与编译开关的具体配置下面是一个典型的.dpr改法假设你把 FastMM4 的源码目录加进了搜索路径program MyLegacyApp; uses FastMM4, // 必须放在第一位初始化段会替换内存管理器 Vcl.Forms, MainUnit in MainUnit.pas {FormMain}; {$R *.res} begin Application.Initialize; Application.MainFormOnTaskbar : True; Application.CreateForm(TFormMain, FormMain); Application.Run; end.逻辑说明FastMM4放在uses首位保证它的initialization在Vcl.Forms之前执行。参数方面FastMM4 的行为由FastMM4Options.inc这个文件控制你需要在源码目录里找到它按需打开开关。最常用的几个开关如下表。编译开关作用适用场景FullDebugMode记录每次分配的调用栈和大小定位泄漏、越界性能下降约 3-10 倍ClearLogFileOnStartup每次启动清空日志避免日志无限增长LogErrorsToFile把错误写入FastMM4_Log.txt现场机器无法调试时EnableMemoryLeakReporting退出时输出未释放块配合 FullDebugMode 使用UseOutputDebugString错误输出到调试器用 IDE 调试时注意FullDebugMode必须配合FastMM4的完整源码包使用不能只引用编译好的 DCU否则调用栈信息会缺失。打开这个开关后程序退出时会在 exe 同目录生成日志里面按「泄漏块大小 申请地址 调用栈」列出所有未释放内存。2.3 验证替换是否生效的两个动作改完之后不要急着跑业务先做两个验证。第一在MainUnit的FormCreate里加一行OutputDebugString(PChar(Format(MM: %p, [MemoryManager])));然后在 IDE 里断点看这个地址是否和 FastMM4 源码里NewMemoryManager的地址一致。第二故意写一个泄漏procedure TFormMain.ButtonLeakClick(Sender: TObject); var P: Pointer; begin GetMem(P, 1024); // 故意不 FreeMem验证泄漏报告 end;点击按钮后关闭程序如果FastMM4_Log.txt里出现了 1024 字节的泄漏块并附带ButtonLeakClick的调用栈说明整套机制已经跑通。这一步是后面所有排查工作的基础跳过它直接上生产环境等于白装。3. FullDebugMode 下读懂泄漏日志与调用栈3.1 日志文件的三个关键区块打开FullDebugMode后程序退出时生成的日志不是随便看看就行的。它通常分三块第一块是「This application has leaked memory」列出每个泄漏块的大小和地址第二块是「The leaked memory blocks were allocated at」给出每个块的调用栈第三块是「The block was allocated by thread」标明线程 ID。真正有用的是第二块因为地址和大小只能告诉你「漏了多少」调用栈才能告诉你「在哪漏的」。调用栈的格式类似The block was allocated at: System._GetMem System.GetMem MainUnit.TFormMain.ButtonLeakClick (Line 42) Vcl.Controls.TControl.Click从下往上读最上面是底层分配函数最下面是你自己的业务代码。如果调用栈里出现大量System.GetMem而没有你的单元名说明泄漏发生在 RTL 或第三方库内部这时候要结合块大小判断——比如固定 64 字节的块反复出现很可能是某个TObject没释放。3.2 用块大小和线程 ID 缩小排查范围日志里同一段调用栈可能对应几十个泄漏块这时候不要一个个看先按大小分组。常见规律TObject实例通常占 16-64 字节字符串缓冲区按内容长度变化动态数组的块大小和元素数量相关。如果你看到大量 32 字节的块来自同一个调用栈基本可以锁定是某个小对象没Free。线程 ID 在多线程项目里尤其重要。Delphi 的多线程如果在线程里Create了对象却忘记在Terminate前释放泄漏日志会显示这些块来自非主线程 ID。这时候要检查TThread.Execute里有没有try...finally保护。3.3 一个真实泄漏的定位过程假设日志里出现这样的记录A memory block has been leaked. The size is: 128 The block was allocated at: System._GetMem System.GetMem System.Classes.TList.Create DataModuleUnit.TDataModule.CreateList (Line 88)TList.Create默认容量是 4 个指针32 位下占 16 字节64 位下占 32 字节但这里显示 128 字节说明TList已经扩容过。回到DataModuleUnit第 88 行发现代码是FList : TList.Create;但TDataModule.Destroy里只写了FList.Clear而没有FList.Free。Clear只释放元素不释放TList本身。改成FreeAndNil(FList)后重新编译泄漏消失。这个案例说明日志给的是线索最终还是要回到代码里核对生命周期。4. 多线程与第三方库场景下的避坑与排查4.1 避坑一FullDebugMode 下程序启动变慢甚至卡死现象打开FullDebugMode后程序启动时间从 2 秒变成 20 秒或者在某些机器上直接卡在启动画面。原因FullDebugMode会为每次分配记录调用栈调用栈的获取依赖StackWalk或RtlCaptureStackBackTrace在大量小对象分配的场景下开销巨大。如果程序启动时加载了几万个对象日志写入和栈回溯会把 CPU 吃满。解决不要在生产环境开FullDebugMode。调试时如果启动阶段就有大量分配可以先用EnableMemoryLeakReporting但不加FullDebugMode只统计泄漏块大小和数量缩小范围后再针对性地打开完整模式。另外FastMM4Options.inc里可以设置FullDebugMode的栈深度默认是 10 层改成 5 层能明显降低开销。4.2 避坑二第三方 DLL 与宿主程序内存管理器冲突现象主程序用了 FastMM4加载某个第三方 DLL 后释放 DLL 里创建的对象时崩溃报「Invalid pointer operation」。原因DLL 有自己的内存管理器实例如果 DLL 里GetMem分配的内存被主程序的FreeMem释放两边管理器不一致就会崩。FastMM4 虽然支持共享内存管理器但需要 DLL 和 EXE 都使用同一份 FastMM4 源码并且正确导出GetMemoryManager接口。解决常见做法是让 DLL 和 EXE 都编译 FastMM4并在 DLL 的.dpr里同样把FastMM4放在uses首位。如果第三方 DLL 无法重新编译那就在边界处做拷贝DLL 返回的数据用LocalAlloc或CoTaskMemAlloc分配宿主用对应的LocalFree释放不要跨模块传递TObject或string。4.3 避坑三日志文件把磁盘写满现象程序运行几天后客户反馈磁盘空间不足发现FastMM4_Log.txt有几十 GB。原因FullDebugMode下每次分配都写日志如果程序有高频分配比如每秒几千次日志增长速度极快。而且默认情况下日志是追加模式不会自动清理。解决在FastMM4Options.inc里打开ClearLogFileOnStartup保证每次启动清空。同时设置LogErrorsToFile只在出错时写而不是每次分配都写。如果必须长期监控可以自己写一个定时任务在程序运行期间定期截断日志文件或者把日志重定向到内存缓冲区只在退出时落盘。4.4 避坑四把 FastMM4 当成万能药忽略业务层引用计数现象装了 FastMM4泄漏报告也看了代码里该Free的都Free了但内存还是涨。原因Delphi 里string、动态数组、接口都是引用计数管理的如果出现循环引用比如两个对象互相持有接口引用计数永远不归零FastMM4 不会报告这些块因为它们「还在被引用」只是引用链形成了环。解决FastMM4 抓的是「没有引用却未释放」的块抓不到「有引用但逻辑上不该再引用」的块。这类问题要靠代码审查和弱引用设计。常见做法是把其中一方改成Pointer或TComponent的非拥有引用打破循环。另外可以用ReportMemoryLeaksOnShutdown配合 FastMM4 一起看但最终还是要回到对象图分析。4.5 避坑五Release 下正常、Debug 下崩溃现象同一个版本Release 编译运行正常Debug 编译一跑就崩报「尝试读取或写入受保护的内存」。原因Debug 下 FastMM4 的越界检测更严格会为每个块分配额外的保护页任何越界写都会立刻触发异常。Release 下这些保护页不存在越界写可能只是覆盖了相邻块的数据暂时不崩但埋下隐患。解决这不是 FastMM4 的问题而是它帮你提前暴露了问题。遇到这种情况不要关掉 FastMM4而是根据崩溃时的调用栈定位越界写的位置。常见元凶是Move、FillChar时长度算错或者动态数组SetLength后用了超出范围的索引。修掉越界Release 下的稳定性也会提升。5. 用 FastMM4 做长期内存监控与回归验证5.1 把泄漏检测接进 CI 的轻量做法FastMM4 默认是交互式调试工具但也可以改造成自动化检测。思路是在测试程序里打开EnableMemoryLeakReporting和LogErrorsToFile程序退出时检查日志文件是否存在且非空。如果非空说明有泄漏CI 直接失败。具体做法是在测试工程的.dpr里加一段{$IFDEF CI} // CI 环境下强制退出码反映泄漏状态 if FileExists(FastMM4_Log.txt) then ExitCode : 1; {$ENDIF}然后在 CI 脚本里先删除旧日志跑完测试后判断退出码。这个做法不需要解析日志内容只判断「有没有泄漏」适合作为回归门禁。如果团队愿意多花点时间可以写一个简单的日志解析脚本按调用栈聚合把新增的泄漏模式挑出来。5.2 用内存快照对比定位「缓慢增长」有些泄漏不是一次性的而是每次操作涨一点跑一天才明显。FastMM4 的退出日志抓不到这种因为程序没退出。这时候可以用「快照对比」在关键操作前后各调用一次GetHeapStatus记录TotalAllocated和TotalFree对比差值。var Before, After: THeapStatus; begin Before : GetHeapStatus; DoBusinessOperation; // 怀疑泄漏的操作 After : GetHeapStatus; if After.TotalAllocated Before.TotalAllocated 1024 then OutputDebugString(PChar(Format(Heap grew by %d bytes, [After.TotalAllocated - Before.TotalAllocated]))); end;参数说明TotalAllocated是当前已分配的总字节数TotalFree是空闲块总字节数。如果每次操作后TotalAllocated都涨且不回落基本可以确认泄漏。这个方法的好处是不依赖 FullDebugMode性能开销小可以在生产环境低频采样。5.3 一个我坚持了多年的习惯每次给老项目接 FastMM4我不会一上来就开FullDebugMode跑全量。我的习惯是先只替换内存管理器不开任何调试开关跑一周确认没有兼容性问题然后打开EnableMemoryLeakReporting收集退出时的泄漏块大小分布最后才针对最大的那几类泄漏打开FullDebugMode抓调用栈。这样每一步都有明确的验证目标不会因为日志太多而放弃。FastMM4 是个好工具但它给的信息需要你带着假设去读而不是指望它直接告诉你答案。希望帮到你。本文还有配套的精品资源点击获取