它可能不是在“泄漏”内存，而是在“囤积”内存。内存只有在应用程序无法释放它时才是“泄漏”的，例如，在它的指针丢失后。
创建对象时占用内存，销毁对象时释放内存（如果该对象被新对象覆盖，则会丢失）。泄漏是指内存从未被释放（在应用程序已经关闭之后）。这可能是在应用程序运行期间对象未被释放的情况，但如果将对象添加到对象列表或数组中，则该列表/数组将继续增长（而不是覆盖），如果对象由应用程序拥有，则它们在应用程序关闭时自动释放，但直到应用程序关闭才释放，FastMM没有什么可报告的，因为没有内存泄漏（应用程序关闭时，内存已全部释放）
内存分析器可以显示当前内存中每个对象的数量以及Objects类（我们也使用AQ Time，它可以做到这一点）。您需要在一小时/2小时/3小时后查看内存配置文件。大多数长时间运行的应用（我所知道的）有一个相当恒定的（长期）存储器需求，并且存储器中的每个对象也保持相当恒定。显然，当应用程序忙碌时，可能会出现峰值，但这些峰值应该会恢复到稳定水平。请查看是否有任何对象计数在持续增长。
我敢打赌，应用程序会动态地创建一些内容，将窗体或应用程序作为其父级，将其添加到列表的末尾，而不是释放它。该对象会一直保留在内存中，直到应用程序关闭，但每个新对象都需要更多的内存。

射进黑暗中：您的应用是否实现了某种类型的缓存？A cache with a bad policy is another name for a memory leak。

你可以尝试一些分析器应用程序，可以跟踪在某个点上分配了什么类型的对象，或者你甚至可以制作自己的工具来转储分配的对象。

最后但并非最不重要的一点是，还可能存在堆碎片问题。这在FastMM4中的可能性要小得多，但无论如何检查它可能是明智的。
最简单的解决方案是在应用程序的某个地方记录堆管理器的统计信息（getheapstatus），并检查FreeBig和FreeSmall是否不是你丢失的大部分内存。如果是，那么堆碎片就是你的主要问题。
Totalallocated字段包含程序使用的内存量。如果这个值很高，说明您正在使用内存，但在关机时释放它。
这可以是任何东西，包括例如周期性地将一些信息记录到备忘录或tstringlist。
在关机时对totalallocated进行适当的日志记录可能有助于确定内存的剩余位置。

我们在Win2008上的中间层服务器也遇到过类似的问题。
如果您在Windows 2008 Server（或Win7）**上使用 *MDAC（ADO）**并执行大量连接，则会发现擦除连接信息的MS代码中存在漏洞。
来自MS：“泄漏发生在用于从连接字符串中删除密码等内容的某些安全代码中。解决方法是在连接字符串中包含以下内容：“Perist Security Info=true"。”