我们有一个虚拟内存上升并持续一天以上的应用程序。两天后，它已攀升至约500MB。 我已经尝试分析了命中数据库的应用程序以及大量的http和soap请求，但我Fastmm4显示没有泄漏。
我不确定如何或何时声明内存，以及虚拟内存上升是否存在问题？
JD
答案 0 :(得分：7)
它可能不是“泄漏”记忆，而是更“囤积”它。在应用程序无法释放内存之前，内存不会泄露。例如在它的指针丢失之后。
创建对象时声明内存，并在对象被销毁时释放（如果对象被新对象覆盖，则会丢失）。泄漏是指从未释放内存（应用程序关闭后）。 可能是在应用程序运行期间未释放对象的情况，但如果将对象添加到对象的列表或数组中，则列表/数组只会保持增长（而不是覆盖），如果对象归对象所有。当应用程序关闭时，应用程序会自动释放，但是直到应用程序关闭，FastMM没有任何报告，因为没有内存泄漏（当应用程序关闭时它已全部免费）
内存分析器可以显示当前在内存中的每个对象的数量以及Objects类（我们也使用AQ Time来执行此操作）。您需要在一小时/ 2小时/ 3小时后查看内存配置文件。大多数长时间运行的应用程序（我所知道的）具有相当恒定（长期）的内存要求，并且内存中的每个对象也保持相当稳定。显然，应用程序繁忙时可能会出现峰值，但这些应该会恢复到稳定水平。看看是否有任何对象数量在不断增长。
我敢打赌，该应用程序是动态创建一个表单或应用程序作为它的父级，在列表的末尾添加它，而不是释放它。该对象位于内存中，直到应用程序关闭，但每个新对象需要更多内存。
答案 1 :(得分：4)
陷入黑暗：你的应用程序是否实现了某些类型的缓存？ A cache with a bad policy is another name for a memory leak
答案 2 :(得分：3)
您可以尝试一些可以跟踪某个点上分配的对象类型的探查器应用程序，或者您甚至可以创建自己的工具来转储已分配的对象。不想做宣传，但我们已经非常成功地使用了AQTime。
答案 3 :(得分：3)
最后但并非最不重要的是，还可能存在堆碎片问题。使用FastMM4的可能性要小得多，但无论如何都要检查它。
最简单的解决方案是在应用程序的某个位置记录heapmanager（getheapstatus）的统计信息，并检查FreeBig和FreeSmall是否不是丢失内存的大部分内容。如果是这样，那么heapfragmentation是你的主要问题。
Totalallocated字段包含程序使用的内存量。如果这个很高，你正在使用内存，但在关机时释放它。
这可能是任何事情，包括例如定期将一些信息记录到备忘录或tstringlist。
关闭时对totalallocated的一些记录良好的记录可能有助于确定内存的剩余位置。
答案 4 :(得分：3)
我们在Win2008上的中间层服务器遇到了类似的问题。
如果您在Windows 2008服务器（或Win7）上使用 MDAC（ADO）并执行大量连接， MS代码中存在漏洞，可以清除连接信息。
来自MS：“泄漏发生在一些安全代码中，用于从连接字符串中删除密码等内容。解决方法可能是在连接字符串中包含以下内容，” Persist Security Info = true < /强>”。“