简介FastMM4 4.97 版本是面向 Delphi 与 FreePascal 开发者的内存管理组件包专门用于解决内存泄漏、重复释放、越界访问等疑难内存错误。压缩包内共 89 个文件以 PAS 源码、DLL 动态库为主辅以 DPR/DProj 工程文件、RES 资源、TXT 说明文档、DFM 窗体定义等整体仅 799KB轻量易集成。目前已有 270 人学习下载。资源内含完整 FastMM4 源码、FastMM4Options.inc 配置选项、FullDebugMode 预编译 DLL、FastMM4_FAQ 与 Readme 文档并附带了多语言消息翻译含简体中文和 BCB/CBuilder 支持文件及示例工程。开发者可直接替换默认内存管理器根据报告定位错误位置也可按需调整分配策略在多线程和动态链接库场景中保持内存管理的高效与稳定是 Delphi 项目内存优化的重要工具。1. FastMM 到底是给 Delphi 解决什么问题的Delphi 应用的GetMem/FreeMem走的是可替换的TMemoryManager换掉默认分配器不只是提速那么简单。FastMM4 作为 Delphi 社区里用得最广的内存管理器替身它同时是分配器、泄漏检测器和边界检查器平时帮你把内存碎片和并发争用压下去出问题时能告诉你某个对象是在哪一行分配、是不是忘了释放。对写了五年以上 Delphi 的人来说FastMM 的意义在于把内存问题从“玄学”变成“证据”。这篇文章沿一条最常用的路线走先把 4.97 接进工程再用它抓内存泄漏然后说清内存池参数怎么调最后把内存检测变成日常回归测试工具。2. 把 FastMM 接进 Delphi 工程的接线方式与最小探针2.1 文件布局里最容易错的一点从 FastMM497 源码包解压后真正参与编译的通常是三个文件FastMM4.pas、FastMM4Options.inc、FastMM4Messages.pas。其中FastMM4.pas要显式加入工程FastMM4Options.inc放在与它相同的目录下因为它是被{$I ...}方式包含进来的配置头。最容易犯的错是把FastMM4.pas拷进工程目录FastMM4Options.inc留在别处IDE 编译时报找不到FastMM4Options.inc或者编译过了但实际用的是另一个目录里的旧配置。我一般会把三个文件单独放一个FastMM497目录然后在 Project Options 的 Search Path 里加进去而不是把FastMM4.pas直接拖进工程。这样工程文件干净切换 Debug 和 Release 配置时也不会误删源文件。2.2 工程 .dpr 里为什么必须把 FastMM4 放第一位FastMM 接管内存管理器是靠自身的initialization段在 RTL 启动时替换TMemoryManager的三个函数指针。uses的顺序决定初始化顺序必须保证FastMM4是工程源文件里的第一个 unit不能放在Forms、System.SysUtils后面。program LeakProbe; uses FastMM4, // 必须第一行至少要在 Forms 之前 System.SysUtils, System.Classes; {$R *.res} begin // 业务代码入口 end.这段代码中FastMM4的initialization会在System.SysUtils初始化之前执行后续所有GetMem、FreeMem、New、Dispose以及对象实例分配都走 FastMM。如果顺序放错RTL 里某些单元已经按默认管理器分配过内存接管时刻太晚泄漏检测会漏掉早期分配极端情况下还会在退出时崩在释放逻辑上。64 位工程同样要保持这个顺序。很多人以为 XE2 之后 64 位编译器自带性能更好的分配器就跳过 FastMM实际 FastMM4 4.97 对 32 位和 64 位都支持64 位下做泄漏检测照样有效只是堆栈回溯的精度可能比 32 位浅一些。2.3 Options 里先开最少的四个开关不做任何配置直接编译FastMM 只是一个更快的内存分配器泄漏检测默认是关的。首次接入时把下面四个开关打开得到的结果最直观。{$define FullDebugMode} {$define EnableMemoryLeakReporting} {$define LogMemoryLeakDetailToFile} {$define ClearLogFileOnStartup}FullDebugMode是总闸它让 FastMM 在每个内存块前后插入调试头并在释放时做填充校验这是检测越界写和重复释放的基础。EnableMemoryLeakReporting控制退出时是否扫描未释放块。LogMemoryLeakDetailToFile把报告写到文本文件比弹窗适合自动化跑批。ClearLogFileOnStartup每次启动清空旧日志避免误读上一次运行的结果。这四个开关配合起来有一个明显代价内存占用会明显增高分配和释放也变慢所以它们只能出现在 Debug 配置里。2.4 最小探针故意泄漏一个 TStringList 验证接线接没接成功靠一个故意泄漏的小程序就能验证。program LeakProbe; uses FastMM4, System.SysUtils, System.Classes; {$R *.res} function CreateLeak: Integer; var L: TStringList; begin L : TStringList.Create; L.Add(delphi-leak); Result : L.Count; end; begin CreateLeak; // 故意不释放 LFastMM 退出时应报告 TStringList 泄漏 end.CreateLeak里创建了TStringList函数返回后没有任何引用指向它也没有调用Free。程序退出时 FastMM 在finalization阶段做全堆扫描发现这个未释放对象后写入日志。运行后去 exe 所在目录找MemoryLeaks.log能看到近似这样的内容泄漏对象类型、分配大小、调用栈。如果看不到先确认FastMM4Options.inc是否真的被编译进工程方法是在FastMM4.pas开头临时{$message hint FastMM4 loaded}编译输出栏里出现这行提示就说明文件被引用了。提示System.SysUtils里也有一个ReportMemoryLeaksOnShutdown变量那是 RTL 自带检测和 FastMM 的报告是两套机制。FastMM 接入后不要再把该变量设为True否则退出时会出两份报告地址格式还对不上。3. 用 FastMM 抓内存泄漏选项、日志与地址回填3.1 调试模式下三种常见泄漏现象怎么区分FullDebugMode打开后泄漏检测能覆盖到三类问题普通的未释放对象、重复释放、释放后继续读写。它们在外层的表现不一样FastMM 的日志关键词也不一样。现象可能原因FastMM 相关开关日志关键词程序退出后日志有未释放对象对象引用丢失或忘记 FreeEnableMemoryLeakReportingLeak运行中偶发 Access Violation释放两次同一指针被两块代码各释放一次FullDebugModeBlock already freed对象内容莫名被改写越界写写穿了相邻内存FullDebugMode调试头被破坏重复释放和越界写在FullDebugMode下会尽早炸出来这比等退出时再看报告有用得多。FastMM 在释放块时会校验块头里的魔数如果发现已经释放过直接报错并打印当时的调用栈。3.2 泄漏日志的字段结构FastMM 写出的日志不同构建版本略有差异但核心字段是稳定的泄漏块地址、分配大小、调用栈。以下是一份相对完整的结构示例。FastMM has detected a memory leak: Block address: 00412AB0 Size: 64 bytes Call Stack: 00402D10 0 System.SysUtils 00403F48 0 LeakProbe.dprSize: 64 bytes用来判断是普通对象还是数组缓冲区TStringList实例本体一般在几十字节量级大块泄漏通常是GetMem手工分配或动态数组。Call Stack里给出的是模块名加偏移地址不能直接当源码行看需要结合 MAP 文件解析。3.3 用 MAP 文件把偏移地址回填到源码行解析调用栈是所有内存检测工具里最磨人的一步FastMM 的做法是让编译器生成详细映射文件然后拿日志里的地址去映射文件里查函数名。在 Delphi 的 Project Options 里找到 Delphi Compiler 下的 Linking把 Map file 选成 Detailed重新编译后 exe 同目录会生成.map文件。MAP 文件内容是分段组织的重点关注 PUBLICS 段它列出了所有函数入口地址。Address Publics by Value 0001:0001A0C0 TStringList.Create 0001:0001B5F4 LeakProbe.CreateLeak日志里如果给出类似00402D10的绝对地址可以先通过任务管理器或调试器拿到模块加载基址再用绝对地址减基址得到段:偏移。通常日志里已经带了模块名这一步在 32 位下按“基址 偏移”换算即可64 位下要注意日志也可能是模块相对偏移直接按偏移在 MAP 里搜。拿到CreateLeak这个函数名后再去 Delphi 的 IDE 里按CtrlShiftG定位函数或者直接在代码编辑器里搜索就能看到泄漏点是函数内哪一个对象创建语句。3.4 注册预期泄漏把误报压下去有些程序退出时确实会残留少量全局缓存比如某些第三方库的全局单例自研代码又改不了。FastMM 提供了注册预期泄漏的机制在程序启动时声明“这一块我提前知道不要报”。uses FastMM4; var Obj: TMyGlobalCache; begin Obj : TMyGlobalCache.Create; RegisterExpectedMemoryLeak(Obj); // 退出时 FastMM 不再把 Obj 当作泄漏 end.RegisterExpectedMemoryLeak接收一个对象实例指针FastMM 在退出扫描时看到该地址会跳过。它也有按类名注册的重载版本但按实例注册更精准不会把一个类的所有实例都豁免。提示这个方法只应在临时绕过第三方库时使用。自研代码里如果出现“大量预期泄漏”本质是清理逻辑缺失别用注册接口掩盖问题。4. FastMM 的内存池结构与性能参数调优4.1 三类块与空闲列表快在哪FastMM 把内存分配按大小切成小、中、大三档每档走不同的管理路径。小块分配是最频繁的FastMM 预先向操作系统申请大块内存再按固定规格切成多个“块槽”同一个规格的空闲块通过链表串起来。分配时先查大小对应的空闲链表有就直接弹出链表节点把块头里的状态位改掉整个过程没有系统调用几十纳秒级别完成。中块和大块的分配次数少但单次占用大FastMM 对它们的处理更接近传统堆管理按地址排序维护空闲区间合并相邻释放块来抑制碎片。这三档之间的阈值是编译期常量写在FastMM4.pas里大多数工程不需要改默认设置已经覆盖了对象实例、字符串、动态数组为主的典型分配模式。所以 FastMM“快”的本质不是算法神奇而是绝大多数分配根本不会触碰操作系统只在用户态的空闲链表上完成指针摘挂。这也意味着释放快的结论依赖于块复用如果工程里频繁地“创建一次、用完释放、再也不碰”池子里攒下的空闲块再快也帮不上忙。4.2 FastMM4Options.inc 里真正影响吞吐的开关调优要分清目标是“压低内存占用”还是“提高分配吞吐”。FullDebugMode这类开关对性能伤害极大不属于调优项只属于调试项。真正实用的配置集中在下面这几类。开关作用坑NeverUninstallFastMM 接管后不卸载避免退出时释放管理结构正式版建议保留DLL 场景必须保留StackTraces记录调用栈让泄漏日志带函数信息开销明显只开在 DebugCatchUseOfFreedInterfaces检测已释放接口被继续引用仅在调试期开发布前关掉FullDebugMode总调试闸包含块头校验和填充检查内存开销最大绝不进 ReleaseNeverUninstall被很多人忽略但它在 DLL 工程里影响非常大。FastMM 一旦卸载后续任何持着 FastMM 分配指针的模块再去释放轻则报地址校验失败重则直接崩溃。这个开关不是性能优化是稳定性的保底。4.3 用 GetMemoryManagerState 观察分配压力调优不能只靠感觉FastMM4 导出的GetMemoryManagerState可以拿到整个内存池的存量快照。var S: TMemoryManagerState; I: Integer; begin GetMemoryManagerState(S); for I : 0 to High(S.SmallBlockTypeStates) do begin WriteLn(Format( blockSize%d allocated%d reserved%d, [S.SmallBlockTypeStates[I].BlockSize, S.SmallBlockTypeStates[I].AllocatedBlockCount, S.SmallBlockTypeStates[I].ReservedBlockCount])); end; end;SmallBlockTypeStates是一组同规格块的状态AllocatedBlockCount是当前被业务代码占用的块数ReservedBlockCount是已经向操作系统申请、但还没有拆出去的空闲块数。如果ReservedBlockCount长期远超AllocatedBlockCount说明池子里堆了大量空闲块内存占用虚高但吞吐没有问题反过来如果ReservedBlockCount很少说明每次分配都在向系统要新内存这时优化方向是减少分配次数而不是调 FastMM。观察的最佳时机是跑完一轮典型业务后而不是程序刚启动时。刚启动时池子还没预热数据参考意义不大。4.4 多线程场景的瓶颈判断FastMM 对多线程有专门处理不同线程的空闲链表有一定隔离降低锁竞争。但线程越多分配模式越杂锁仍然可能在特定分配大小上打架。判断瓶颈是不是 FastMM 本身先看业务代码里有没有“循环里反复Create/Free同一个对象”这类写法这是最常见的伪瓶颈。真正需要调 FastMM 时先用 4.3 里的快照看存量再结合两个时间点做对比。连续两次快照之间AllocatedBlockCount变化不大但耗时很高说明问题在业务逻辑不在内存管理器。FastMM 不是万能的它只能让你看见分配次数和块复用情况不能替你把对象生命周期改好。5. 把 FastMM 当作回归测试工具的验证技巧5.1 用分配余额检测每次重构后的内存变化Delphi 工程里很多内存泄漏是重构时引入的比如把一个全局对象改成局部创建但忘了释放。避免回归的一个实用做法是把分配余额检查写成一个测试辅助函数跑完被测流程后比较前后快照。function AllocDelta: NativeInt; var B0, B1: TMemoryManagerState; begin GetMemoryManagerState(B0); RunTestScenario(); GetMemoryManagerState(B1); Result : NativeInt(B1.TotalAllocatedGranularBytes) - NativeInt(B0.TotalAllocatedGranularBytes); end;这里的RunTestScenario是需要验证的业务流程测试前后各取一次TotalAllocatedGranularBytes差值就是流程结束后的净内存变化。正常流程应该等于零大于零说明有泄漏或缓存未回收小于零说明有外部模块释放了不归本流程管的块同样要查。这个函数只适合做回归判断不适合找第一个泄漏点。第一次跑出大额差值时先回到第 3 章用LogMemoryLeakDetailToFile把全量泄漏日志导出来逐条看。5.2 挖出“隐藏泄漏”的分配计数变化有些泄漏不会立刻体现为字节数上涨比如内部对象池反复申请又释放总量平稳但分配次数飙升。除了字节差还要看GetMemoryManagerState里SmallBlockTypeStates的累计分配计数。var S: TMemoryManagerState; I: Integer; begin GetMemoryManagerState(S); for I : 0 to High(S.SmallBlockTypeStates) do if S.SmallBlockTypeStates[I].AllocatedBlockCount 0 then WriteLn(I, : , S.SmallBlockTypeStates[I].AllocatedBlockCount); end;把这段放进测试辅助函数和AllocDelta配合使用字节差为零但某规格块AllocatedBlockCount不为零说明有短生命周期对象被遗留到了测试结束点。这时候再结合泄漏日志里的调用栈基本能定位到具体单元。5.3 发布分支的检查清单FastMM 可以留在正式版里当高性能分配器但调试相关的开关必须清干净。发布前按以下顺序核对一遍检查项结果FullDebugMode在 Release 里为注释状态必须关EnableMemoryLeakReporting保持关闭防止退出时扫描拖慢关闭速度StackTraces关闭避免分支跳转和地址记录开销FastMM4Options.inc与FastMM4.pas同目录防止 Release 误用旧配置NeverUninstall保留打开防止 DLL 场景退出崩溃最后在LeakProbe这类最小探针工程上把 Release 配置完整跑一遍确认没有MemoryLeaks.log生成再用GetMemoryManagerState对比一次空跑快照确保没有残留分配。这套流程走完FastMM 在正式环境里就是纯分配器不会再干扰业务代码。本文还有配套的精品资源点击获取 
长河君 · 2026/9/16 0:41:50 · 阅读 1.2k Delphi内存管理实战：FastMM泄漏检测与性能调优指南
简介FastMM4 4.97 版本是面向 Delphi 与 FreePascal 开发者的内存管理组件包专门用于解决内存泄漏、重复释放、越界访问等疑难内存错误。压缩包内共 89 个文件以 PAS 源码、DLL 动态库为主辅以 DPR/DProj 工程文件、RES 资源、TXT 说明文档、DFM 窗体定义等整体仅 799KB轻量易集成。目前已有 270 人学习下载。资源内含完整 FastMM4 源码、FastMM4Options.inc 配置选项、FullDebugMode 预编译 DLL、FastMM4_FAQ 与 Readme 文档并附带了多语言消息翻译含简体中文和 BCB/CBuilder 支持文件及示例工程。开发者可直接替换默认内存管理器根据报告定位错误位置也可按需调整分配策略在多线程和动态链接库场景中保持内存管理的高效与稳定是 Delphi 项目内存优化的重要工具。1. FastMM 到底是给 Delphi 解决什么问题的Delphi 应用的GetMem/FreeMem走的是可替换的TMemoryManager换掉默认分配器不只是提速那么简单。FastMM4 作为 Delphi 社区里用得最广的内存管理器替身它同时是分配器、泄漏检测器和边界检查器平时帮你把内存碎片和并发争用压下去出问题时能告诉你某个对象是在哪一行分配、是不是忘了释放。对写了五年以上 Delphi 的人来说FastMM 的意义在于把内存问题从“玄学”变成“证据”。这篇文章沿一条最常用的路线走先把 4.97 接进工程再用它抓内存泄漏然后说清内存池参数怎么调最后把内存检测变成日常回归测试工具。2. 把 FastMM 接进 Delphi 工程的接线方式与最小探针2.1 文件布局里最容易错的一点从 FastMM497 源码包解压后真正参与编译的通常是三个文件FastMM4.pas、FastMM4Options.inc、FastMM4Messages.pas。其中FastMM4.pas要显式加入工程FastMM4Options.inc放在与它相同的目录下因为它是被{$I ...}方式包含进来的配置头。最容易犯的错是把FastMM4.pas拷进工程目录FastMM4Options.inc留在别处IDE 编译时报找不到FastMM4Options.inc或者编译过了但实际用的是另一个目录里的旧配置。我一般会把三个文件单独放一个FastMM497目录然后在 Project Options 的 Search Path 里加进去而不是把FastMM4.pas直接拖进工程。这样工程文件干净切换 Debug 和 Release 配置时也不会误删源文件。2.2 工程 .dpr 里为什么必须把 FastMM4 放第一位FastMM 接管内存管理器是靠自身的initialization段在 RTL 启动时替换TMemoryManager的三个函数指针。uses的顺序决定初始化顺序必须保证FastMM4是工程源文件里的第一个 unit不能放在Forms、System.SysUtils后面。program LeakProbe; uses FastMM4, // 必须第一行至少要在 Forms 之前 System.SysUtils, System.Classes; {$R *.res} begin // 业务代码入口 end.这段代码中FastMM4的initialization会在System.SysUtils初始化之前执行后续所有GetMem、FreeMem、New、Dispose以及对象实例分配都走 FastMM。如果顺序放错RTL 里某些单元已经按默认管理器分配过内存接管时刻太晚泄漏检测会漏掉早期分配极端情况下还会在退出时崩在释放逻辑上。64 位工程同样要保持这个顺序。很多人以为 XE2 之后 64 位编译器自带性能更好的分配器就跳过 FastMM实际 FastMM4 4.97 对 32 位和 64 位都支持64 位下做泄漏检测照样有效只是堆栈回溯的精度可能比 32 位浅一些。2.3 Options 里先开最少的四个开关不做任何配置直接编译FastMM 只是一个更快的内存分配器泄漏检测默认是关的。首次接入时把下面四个开关打开得到的结果最直观。{$define FullDebugMode} {$define EnableMemoryLeakReporting} {$define LogMemoryLeakDetailToFile} {$define ClearLogFileOnStartup}FullDebugMode是总闸它让 FastMM 在每个内存块前后插入调试头并在释放时做填充校验这是检测越界写和重复释放的基础。EnableMemoryLeakReporting控制退出时是否扫描未释放块。LogMemoryLeakDetailToFile把报告写到文本文件比弹窗适合自动化跑批。ClearLogFileOnStartup每次启动清空旧日志避免误读上一次运行的结果。这四个开关配合起来有一个明显代价内存占用会明显增高分配和释放也变慢所以它们只能出现在 Debug 配置里。2.4 最小探针故意泄漏一个 TStringList 验证接线接没接成功靠一个故意泄漏的小程序就能验证。program LeakProbe; uses FastMM4, System.SysUtils, System.Classes; {$R *.res} function CreateLeak: Integer; var L: TStringList; begin L : TStringList.Create; L.Add(delphi-leak); Result : L.Count; end; begin CreateLeak; // 故意不释放 LFastMM 退出时应报告 TStringList 泄漏 end.CreateLeak里创建了TStringList函数返回后没有任何引用指向它也没有调用Free。程序退出时 FastMM 在finalization阶段做全堆扫描发现这个未释放对象后写入日志。运行后去 exe 所在目录找MemoryLeaks.log能看到近似这样的内容泄漏对象类型、分配大小、调用栈。如果看不到先确认FastMM4Options.inc是否真的被编译进工程方法是在FastMM4.pas开头临时{$message hint FastMM4 loaded}编译输出栏里出现这行提示就说明文件被引用了。提示System.SysUtils里也有一个ReportMemoryLeaksOnShutdown变量那是 RTL 自带检测和 FastMM 的报告是两套机制。FastMM 接入后不要再把该变量设为True否则退出时会出两份报告地址格式还对不上。3. 用 FastMM 抓内存泄漏选项、日志与地址回填3.1 调试模式下三种常见泄漏现象怎么区分FullDebugMode打开后泄漏检测能覆盖到三类问题普通的未释放对象、重复释放、释放后继续读写。它们在外层的表现不一样FastMM 的日志关键词也不一样。现象可能原因FastMM 相关开关日志关键词程序退出后日志有未释放对象对象引用丢失或忘记 FreeEnableMemoryLeakReportingLeak运行中偶发 Access Violation释放两次同一指针被两块代码各释放一次FullDebugModeBlock already freed对象内容莫名被改写越界写写穿了相邻内存FullDebugMode调试头被破坏重复释放和越界写在FullDebugMode下会尽早炸出来这比等退出时再看报告有用得多。FastMM 在释放块时会校验块头里的魔数如果发现已经释放过直接报错并打印当时的调用栈。3.2 泄漏日志的字段结构FastMM 写出的日志不同构建版本略有差异但核心字段是稳定的泄漏块地址、分配大小、调用栈。以下是一份相对完整的结构示例。FastMM has detected a memory leak: Block address: 00412AB0 Size: 64 bytes Call Stack: 00402D10 0 System.SysUtils 00403F48 0 LeakProbe.dprSize: 64 bytes用来判断是普通对象还是数组缓冲区TStringList实例本体一般在几十字节量级大块泄漏通常是GetMem手工分配或动态数组。Call Stack里给出的是模块名加偏移地址不能直接当源码行看需要结合 MAP 文件解析。3.3 用 MAP 文件把偏移地址回填到源码行解析调用栈是所有内存检测工具里最磨人的一步FastMM 的做法是让编译器生成详细映射文件然后拿日志里的地址去映射文件里查函数名。在 Delphi 的 Project Options 里找到 Delphi Compiler 下的 Linking把 Map file 选成 Detailed重新编译后 exe 同目录会生成.map文件。MAP 文件内容是分段组织的重点关注 PUBLICS 段它列出了所有函数入口地址。Address Publics by Value 0001:0001A0C0 TStringList.Create 0001:0001B5F4 LeakProbe.CreateLeak日志里如果给出类似00402D10的绝对地址可以先通过任务管理器或调试器拿到模块加载基址再用绝对地址减基址得到段:偏移。通常日志里已经带了模块名这一步在 32 位下按“基址 偏移”换算即可64 位下要注意日志也可能是模块相对偏移直接按偏移在 MAP 里搜。拿到CreateLeak这个函数名后再去 Delphi 的 IDE 里按CtrlShiftG定位函数或者直接在代码编辑器里搜索就能看到泄漏点是函数内哪一个对象创建语句。3.4 注册预期泄漏把误报压下去有些程序退出时确实会残留少量全局缓存比如某些第三方库的全局单例自研代码又改不了。FastMM 提供了注册预期泄漏的机制在程序启动时声明“这一块我提前知道不要报”。uses FastMM4; var Obj: TMyGlobalCache; begin Obj : TMyGlobalCache.Create; RegisterExpectedMemoryLeak(Obj); // 退出时 FastMM 不再把 Obj 当作泄漏 end.RegisterExpectedMemoryLeak接收一个对象实例指针FastMM 在退出扫描时看到该地址会跳过。它也有按类名注册的重载版本但按实例注册更精准不会把一个类的所有实例都豁免。提示这个方法只应在临时绕过第三方库时使用。自研代码里如果出现“大量预期泄漏”本质是清理逻辑缺失别用注册接口掩盖问题。4. FastMM 的内存池结构与性能参数调优4.1 三类块与空闲列表快在哪FastMM 把内存分配按大小切成小、中、大三档每档走不同的管理路径。小块分配是最频繁的FastMM 预先向操作系统申请大块内存再按固定规格切成多个“块槽”同一个规格的空闲块通过链表串起来。分配时先查大小对应的空闲链表有就直接弹出链表节点把块头里的状态位改掉整个过程没有系统调用几十纳秒级别完成。中块和大块的分配次数少但单次占用大FastMM 对它们的处理更接近传统堆管理按地址排序维护空闲区间合并相邻释放块来抑制碎片。这三档之间的阈值是编译期常量写在FastMM4.pas里大多数工程不需要改默认设置已经覆盖了对象实例、字符串、动态数组为主的典型分配模式。所以 FastMM“快”的本质不是算法神奇而是绝大多数分配根本不会触碰操作系统只在用户态的空闲链表上完成指针摘挂。这也意味着释放快的结论依赖于块复用如果工程里频繁地“创建一次、用完释放、再也不碰”池子里攒下的空闲块再快也帮不上忙。4.2 FastMM4Options.inc 里真正影响吞吐的开关调优要分清目标是“压低内存占用”还是“提高分配吞吐”。FullDebugMode这类开关对性能伤害极大不属于调优项只属于调试项。真正实用的配置集中在下面这几类。开关作用坑NeverUninstallFastMM 接管后不卸载避免退出时释放管理结构正式版建议保留DLL 场景必须保留StackTraces记录调用栈让泄漏日志带函数信息开销明显只开在 DebugCatchUseOfFreedInterfaces检测已释放接口被继续引用仅在调试期开发布前关掉FullDebugMode总调试闸包含块头校验和填充检查内存开销最大绝不进 ReleaseNeverUninstall被很多人忽略但它在 DLL 工程里影响非常大。FastMM 一旦卸载后续任何持着 FastMM 分配指针的模块再去释放轻则报地址校验失败重则直接崩溃。这个开关不是性能优化是稳定性的保底。4.3 用 GetMemoryManagerState 观察分配压力调优不能只靠感觉FastMM4 导出的GetMemoryManagerState可以拿到整个内存池的存量快照。var S: TMemoryManagerState; I: Integer; begin GetMemoryManagerState(S); for I : 0 to High(S.SmallBlockTypeStates) do begin WriteLn(Format( blockSize%d allocated%d reserved%d, [S.SmallBlockTypeStates[I].BlockSize, S.SmallBlockTypeStates[I].AllocatedBlockCount, S.SmallBlockTypeStates[I].ReservedBlockCount])); end; end;SmallBlockTypeStates是一组同规格块的状态AllocatedBlockCount是当前被业务代码占用的块数ReservedBlockCount是已经向操作系统申请、但还没有拆出去的空闲块数。如果ReservedBlockCount长期远超AllocatedBlockCount说明池子里堆了大量空闲块内存占用虚高但吞吐没有问题反过来如果ReservedBlockCount很少说明每次分配都在向系统要新内存这时优化方向是减少分配次数而不是调 FastMM。观察的最佳时机是跑完一轮典型业务后而不是程序刚启动时。刚启动时池子还没预热数据参考意义不大。4.4 多线程场景的瓶颈判断FastMM 对多线程有专门处理不同线程的空闲链表有一定隔离降低锁竞争。但线程越多分配模式越杂锁仍然可能在特定分配大小上打架。判断瓶颈是不是 FastMM 本身先看业务代码里有没有“循环里反复Create/Free同一个对象”这类写法这是最常见的伪瓶颈。真正需要调 FastMM 时先用 4.3 里的快照看存量再结合两个时间点做对比。连续两次快照之间AllocatedBlockCount变化不大但耗时很高说明问题在业务逻辑不在内存管理器。FastMM 不是万能的它只能让你看见分配次数和块复用情况不能替你把对象生命周期改好。5. 把 FastMM 当作回归测试工具的验证技巧5.1 用分配余额检测每次重构后的内存变化Delphi 工程里很多内存泄漏是重构时引入的比如把一个全局对象改成局部创建但忘了释放。避免回归的一个实用做法是把分配余额检查写成一个测试辅助函数跑完被测流程后比较前后快照。function AllocDelta: NativeInt; var B0, B1: TMemoryManagerState; begin GetMemoryManagerState(B0); RunTestScenario(); GetMemoryManagerState(B1); Result : NativeInt(B1.TotalAllocatedGranularBytes) - NativeInt(B0.TotalAllocatedGranularBytes); end;这里的RunTestScenario是需要验证的业务流程测试前后各取一次TotalAllocatedGranularBytes差值就是流程结束后的净内存变化。正常流程应该等于零大于零说明有泄漏或缓存未回收小于零说明有外部模块释放了不归本流程管的块同样要查。这个函数只适合做回归判断不适合找第一个泄漏点。第一次跑出大额差值时先回到第 3 章用LogMemoryLeakDetailToFile把全量泄漏日志导出来逐条看。5.2 挖出“隐藏泄漏”的分配计数变化有些泄漏不会立刻体现为字节数上涨比如内部对象池反复申请又释放总量平稳但分配次数飙升。除了字节差还要看GetMemoryManagerState里SmallBlockTypeStates的累计分配计数。var S: TMemoryManagerState; I: Integer; begin GetMemoryManagerState(S); for I : 0 to High(S.SmallBlockTypeStates) do if S.SmallBlockTypeStates[I].AllocatedBlockCount 0 then WriteLn(I, : , S.SmallBlockTypeStates[I].AllocatedBlockCount); end;把这段放进测试辅助函数和AllocDelta配合使用字节差为零但某规格块AllocatedBlockCount不为零说明有短生命周期对象被遗留到了测试结束点。这时候再结合泄漏日志里的调用栈基本能定位到具体单元。5.3 发布分支的检查清单FastMM 可以留在正式版里当高性能分配器但调试相关的开关必须清干净。发布前按以下顺序核对一遍检查项结果FullDebugMode在 Release 里为注释状态必须关EnableMemoryLeakReporting保持关闭防止退出时扫描拖慢关闭速度StackTraces关闭避免分支跳转和地址记录开销FastMM4Options.inc与FastMM4.pas同目录防止 Release 误用旧配置NeverUninstall保留打开防止 DLL 场景退出崩溃最后在LeakProbe这类最小探针工程上把 Release 配置完整跑一遍确认没有MemoryLeaks.log生成再用GetMemoryManagerState对比一次空跑快照确保没有残留分配。这套流程走完FastMM 在正式环境里就是纯分配器不会再干扰业务代码。本文还有配套的精品资源点击获取