问题标签 [resource-leak]

开发人员可以通过多种方式被 .NET 中的无意资源泄漏所困扰。我认为将它们聚集在一个地方会很有用。

请为每个项目添加一个答案，以便获得最佳投票:)

我使用SetTimerAPI，我看到很多这样的代码：

我必须调用KillTimer还是系统会在进程退出时自动释放资源？忘记调用KillTimer会导致资源泄漏吗？

我知道如果不需要计时器，它可以被KillTimer. 但是必须手动销毁吗？

我想知道是否可以使用 WinDbg 来了解导致分配句柄的调用堆栈。

例如：

在构建此示例并在 WinDbg 中启动它之后，是否可以在行上方的示例中获取分配句柄的调用堆栈：

我正在用!handle命令四处寻找，但到目前为止没有任何进展。

这与处理泄漏分析有关。我知道，!htrace -enable但这!htrace -diff是一个不同的使用场景（除非有某种组合方式或其他使用向量，请提供信息）。

我有个疑问。我初始化 COM，做 CoCreateInstance 并使用一些接口。我可以在不调用 Release 的情况下调用 CoUninitialize 吗？它会导致任何内存/资源泄漏吗？

提前致谢，-Mani。

天真地，我期望 ThreadLocal 是某种 Thread 到值类型的 WeakHashMap。所以当我得知 ThreadLocal 的值实际上保存在 Thread 的映射中时，我有点困惑。为什么这样做？如果值保存在 ThreadLocal 本身中，我希望不会存在与 ThreadLocal 相关的资源泄漏。

澄清：我在想类似的东西

据我所见，这将防止奇怪的问题，即如果值以某种方式强烈引用 ThreadLocal 本身，则 ThreadLocal 及其剩余值都不会被垃圾收集，直到 Thread 死亡。（当 ThreadLocal 是值所引用的类上的静态变量时，可能会发生这种情况的最狡猾的形式。现在，由于无法收集对象及其类，因此在应用程序服务器中重新部署时会出现大量资源泄漏。）

问题：

有没有一种简单的方法来获取正在运行的应用程序中泄漏的资源类型列表？IOW 通过连接到应用程序？

我知道 memproof 可以做到，但它的速度非常慢，以至于应用程序甚至不会持续一分钟。大多数taskmanager喜欢可以显示数字，但不能显示类型。

检查本身是灾难性的（停止应用程序进程）不是问题，因为如果我接近（或者至少我希望），我可以使用 taskmgr 检查

也欢迎任何其他关于资源泄漏搜索（所以不是内存）的见解。

背景：

我有一个 Delphi 7/2006/2009 应用程序（与所有三个一起编译），大约几周后它开始变得有趣。然而，它只在其中一个运行的地方，在其他几个系统上运行直到断电。

我试图放入一些调试代码来缩小问题范围。并发现异常是 EOutofResources 保存文件。（文件保存每天可能发生数千次）。

我试图排除内存泄漏（使用 fastmm），但由于数据流非常高（来自千兆工业相机的 60MByte/s），我只能排除使用 fastmm 的“爬行”内存泄漏，而不是快速闪烁耗尽的内存泄漏它发生时的记忆。如果出现问题，应用程序会在半分钟内填满内存。

主要的嫌疑人是文件句柄，它们以某种方式留下了一些错误和 TMetafiles（流式传输到这些文件）。次要嫌疑人是 VST、popupmenu 和 tframes

更新：

另一个可能的提示：它在 D7 上运行了两年，现在问题出在 Turbo Explorer（我用于未转换为 D2009 的稳定项目）。

Paul-Jan：因为它每周只发生一次（而且可能在晚上发生），所以信息获取速度很慢。这就是为什么我问这个问题的原因，需要结合我星期四在那里的东西。简而言之：不，我不知道 100% 肯定。我打算带上整个 Systemtools 集合，看看能不能找到一些东西（因为那样它会运行好几天）。我也有机会看到打开的文件。（也许应该尝试找到一些 mingw lsof 并安排它）

但是该应用程序看到的 GUI 操作非常少（它是一个机器视觉检查应用程序），除了屏幕刷新 +/- 15/s 这是 tbitmap stretchdraw + tmetafile，但我在保存到磁盘时收到此错误（TFileStream）句柄可能真的累。然而在同一个流中，TMetafile 也被保存到流中，这是后来的应用程序不再拥有的东西，它们可以运行几个月。

- - - - - - - - - - 更新

我已经搜索和搜索，并设法在体外重现问题两到三遍。当 memusage 为 +/- 256MB（系统有 2GB），用户对象 200，gdi 对象 500，没有一个文件比预期的打开时，问题发生了。

这并不是真正的例外。我确实注意到我泄漏了少量句柄，可能是由于重新父框架（VCL 中的某些内容似乎泄漏了 HPalette），但我怀疑核心原因是另一个问题。我重用 TMetafile，并在两者之间清除它。我认为清除元文件并不会真正（总是？）调整资源的大小，最终整个 tmetafile 池中的每个元文件都以最大大小，并且有 20-40+ tmetafiles（每个可以是几个 100ks）这将打到桌面堆限制。

那是理论上的，但我会尝试通过将客户的桌面限制设置为 10MB 来验证这一点，但如果这有任何改变，我还需要几周的时间才能确认。这个理论也证实了为什么这台机器是特殊的（这台机器可能自然平均有稍大的元文件）。偶尔在池中释放和重新创建 tmetafile 也可能有所帮助。

幸运的是，所有这些问题（tmetafile 和 reparenting）都已经在新一代应用程序中设计出来了。

由于特殊情况（以及我的测试窗口非常有限的事实），这将需要一段时间，但我决定暂时接受桌面堆作为示例（尽管 GDILeaks 的东西也有点用）。

审计揭示了线程中 GDI 类型使用的另一件事（尽管仅将 tmetafiles（未使用或以其他方式连接）保存到流中。

------------- 更新 2。

增加桌面限制似乎只会略微增加问题发生的时间。

不幸的是，我无法进一步跟进，因为机器已更新到没有问题的框架的更新版本。

总之，我只能说明从旧框架到新框架的三个核心修改：

• 我不再通过重新设置框架来更改屏幕。我现在使用我隐藏和显示的表单。我改变了这一点，因为我也因此而发生了非常罕见的崩溃或异常（可以点击离开）。崩溃都是在操作 GUI 时发生的，不像主要问题那样自发
• 发生崩溃的例程处理 TMetafile。TMetafile 已被设计出来，取而代之的是一种更简单的自制格式。（基本上是带有 Opengl 顶点的数组）
• tbitmap 不再使用 tmetafile 覆盖在其上绘制，而是使用 OpenGL 进行绘制。

当然它也可能是别的东西，在上述部分的重写中得到了改变，修复了一些非常讨厌的细节错误。这一定是一个非常糟糕的系统，因为我尽可能多地分析了上述系统。

在一些私人邮件讨论后于2012 年 11 月更新：回想起来，下一步将是向元文件对象添加一个计数器，并在每 x * 1000 次左右使用时简单地重新实例化它们，看看这是否会改变任何东西。如果您有类似的问题，请尝试查看是否可以定期销毁和重新初始化动态分配的长寿命资源。

我一直在阅读 .NET Threading 并正在研究一些使用ManualResetEvent的代码。我在互联网上找到了很多代码示例。但是，在阅读WaitHandle的文档时，我看到了以下内容：

WaitHandle 实现了 Dispose 模式。请参阅实施 Finalize 和 Dispose 以清理非托管资源。

没有一个样本似乎在他们创建的 ManualResetEvent 对象上调用 .Close()，即使是pfxteam 博客中不错的递归和并发文章（编辑- 这有一个我错过的 using 块）。这只是示例监督，还是不需要？我很好奇，因为 WaitHandle “封装了操作系统特定的对象”，因此很容易发生资源泄漏。

我在旧版应用程序中使用 ADO.NET (.NET 1.1)。我知道如果在将连接提供给 DataAdapter 之前尚未手动打开连接，则 DataAdapter.Fill() 会打开和关闭连接。

我的问题：如果 .Fill() 导致异常，它是否也会关闭连接？（由于无法访问 SQL Server 或其他原因）。它是泄漏连接还是有内置的 finally 子句来确保连接被关闭。

代码示例：

我正在尝试调试打印机驱动程序中的内存泄漏。我很确定这是资源泄漏，而不仅仅是普通的内存泄漏，因为在 windbg 中使用 !heap -s 分析堆并没有显示任何增加。如何使用 windbg 监控其他类型的对象？GDI 对象和打开句柄的数量也没有增长，那会是什么？

内存泄漏的症状是私有字节增长到 180Mb，然后打印开始遇到随机问题。

我正在创建一个仪表板应用程序，它在FlowLayoutPanel.

每个“项目”是UserControl由 12 个文本框或标签组成的。

我的应用程序查询数据库，然后为每条记录创建一个“项目”实例，在将数据添加到FlowLayoutPanel.

在面板中添加了大约 560 个项目后，我注意到USER Objects我的任务管理器中的计数已经上升到大约 7300，这比我机器上的任何其他应用程序都要大得多。

我认为 560 * 13（12 个标签加上 UserControl 本身）是 7280。所以这突然泄露了所有对象的来源......

知道在 Windows 认输之前有 10,000 个 USER 对象限制，我试图找出更好的方法将这些“项目”绘制到FlowLayoutPanel.

到目前为止，我的想法如下：

1. 用户绘制“项目”，使用graphics.DrawText和DrawImage代替许多标签。我希望这意味着 1 item = 1 USER Object，而不是 13。

2. 拥有“项目”的 1 个实例，然后对于每条记录，填充实例并使用该Control.DrawToBitmap()方法抓取图像，然后在FlowLayoutPanel（或类似）中使用该图像

所以...有没有人有任何其他建议？？？

PS 这是一个可缩放的界面，所以我已经排除了“分页”，因为需要一次查看所有项目