问题标签 [resource-leak]

这是我上一个问题的后续问题。

正如我上一个问题的答案中所建议的，我使用ProcessExplorer分析了我的应用程序用来查找句柄泄漏的句柄列表。

泄漏的句柄属于Section类型。

究竟什么是节句柄，它在哪里使用以及什么会导致节句柄泄漏？

我没有在我的代码中使用内存映射文件。

我正在使用 Jersey v10 并编写了以下代码。这是关闭 Jersey 客户端连接以避免内存泄漏的正确方法吗？在此之前我最终没有对他进行任何调用。

TIA，维杰

我们有一个包含数千个表单的 Windows 窗体应用程序。

其中许多通过 ShowDialog() 方法临时显示为对话框。

这个应用程序已经存在多年，我们发现由于表单或它使用的控件中的各种资源泄漏，许多表单没有及时收集垃圾。

具体来说，我们发现了 GDI+ 资源没有被正确处理的例子，尽管可能还有其他类型的资源泄漏尚未被描述。

虽然解决这个问题的正确方法显然是遍历每一个表单和每一个控件，并消除所有的资源问题。这需要一些时间来完成。

作为短期替代方案，我们发现在表单上显式调用 Dispose() 似乎会启动垃圾收集过程，并且会立即释放表单及其资源。

我的问题是，将每个表单的 ShowDialog() 块包装在 using 语句中，以便在显示表单后调用 Dispose() 是否是一种合理的解决方法，这也是一个普遍的好习惯吗？

例如，从这里更改现有代码：

对此：

在我们的测试中，MyForm 的 Dispose() 方法永远不会为第一个示例调用，但它会立即为第二个示例调用。

当我们花时间跟踪每个特定的资源问题时，这似乎是一种合理的短期解决方法吗？

是否有其他我们可以考虑的短期解决方法和/或用于识别和解决这些类型的资源问题的方法？

在 NSDictionary 中复制密钥后，我遇到了崩溃。我正在使用 ARC。是什么原因？

我有一个带有 Master-Details 视图的应用程序。当您从“主”列表中选择一个项目时，它会使用一些图像（通过 RenderTargetBitmap 创建）填充“详细信息”区域。

每次我从列表中选择不同的主项时，我的应用程序使用的 GDI 句柄的数量（如 Process Explorer 中所报告的）都会增加 - 并最终在使用 10,000 个 GDI 句柄时下降（或有时锁定）。

我不知道如何解决这个问题，所以任何关于我做错了什么的建议（或者只是关于如何获取更多信息的建议）将不胜感激。

我在一个名为“DoesThisLeak”的新 WPF 应用程序 (.NET 4.0) 中将我的应用程序简化为以下内容：

在 MainWindow.xaml.cs

在 MainWindow.xaml

如果单击列表中的第一项，然后按住向下光标键，则可以重现该问题。

通过查看带有 SOS 的 WinDbg 中的 !gcroot ，我找不到任何使这些 RenderTargetBitmap 对象保持活力的东西，但如果我这样做!dumpheap -type System.Windows.Media.Imaging.RenderTargetBitmap，仍然会显示其中几千个尚未收集的对象。

有一个 GDI 泄漏的应用程序，最终将达到 10,000 个分配的 GDI 对象并崩溃。我尝试将GDIProcessHandleQuota增加到 20,000，但是当达到 10,000 个对象时程序仍然崩溃。我们目前正在修复这个漏洞，但出于好奇——有没有办法增加单个进程的 GDI 限制？还是 10k 是单个应用程序的硬限制？

我有一堆 EAGAIN 试图 fork() 或产生线程，这让我相信我在某处泄漏资源。

在 POSIX 中，是否有可能从进程本身内部获取以下内容：

• 活动 pthread 数
• 活动子进程数
• 活动管道数
• 活动套接字的数量（或者这个和管道可能会被视为文件描述符？）

还是必须手动计算这些？他们已经有柜台了，但我认为其中一个正在泄漏。

我正在使用 FastMM 调试我的程序，它报告的许多内存泄漏似乎是合法的内存分配，而不是实际的内存泄漏。

例如，

TConnObj 是经常用于创建对象并在程序不再需要时销毁的类。但是，FastMM 报告它是实际的内存泄漏。那么，在查看 FastMM 内存泄漏日志文件时，如何判断哪个是哪个？

我必须使用本机库（这不是我的决定）。该库已经有一个 JNI 包装器，并且示例 Android NDK 代码有效。但库初始化例程返回本地句柄，开发人员需要正确关闭它们。

现在，有一个有趣的问题：从哪里调用 close_handle 例程？

至少在理论上，每次不正确的终止都可能导致临时文件留在磁盘上的某处或某种其他类型的资源泄漏。

库初始化需要 0.5 到 1 秒，并且会消耗大量内存。

anActivity是一个控制器（MVC 意义上的），Android 可以因为自己的原因杀死它，包括转动设备，并且唯一保证被调用的函数是onPause(). 所以onPause/onResume对于长时间的资源消耗操作来说是一个不好的地方。

（我知道android:configChanges="keyboardHidden|orientation"，但我更喜欢不需要它的解决方案。）

Application将是一个理想的候选人（我认为库是模型的一部分），但没有“应用程序终止”事件。

Service听起来很有希望，本机库是一项服务，但我只是不明白如何才能获得所需的行为：当应用程序终止时必须关闭句柄。

超时：听起来像是一种权衡，但实际上它保证了内存在需要的那一刻不可用，但几秒钟后就会变得可用。

有时，如果我们的文件服务器很慢并且页面在超时之前没有完成，ASP.Net 会使用 ThreadAbortException 对其进行处理。如果这种情况发生在 Win32Native.CreateFile 中，它将使文件句柄处于锁定状态，直到我们执行 iisreset。

这是 .NET 中的缺陷吗？我们能做些什么来解决这个糟糕的想法，比如将超时时间提高到某个巨大的数字......我认为 ThreadAbort.Reset 不会有帮助，因为损坏已经完成，我什至没有返回文件句柄从 FileStream 自己关闭它。

在 Microsoft.Win32.Win32Native.CreateFile（字符串 lpFileName，Int32 dwDesiredAccess，FileShare dwShareMode，SECURITY_ATTRIBUTES securityAttrs，FileMode dwCreationDisposition，Int32 dwFlagsAndAttributes，IntPtr hTemplateFile）

在 Microsoft.Win32.Win32Native.SafeCreateFile（字符串 lpFileName，Int32 dwDesiredAccess，FileShare dwShareMode，SECURITY_ATTRIBUTES securityAttrs，FileMode dwCreationDisposition，Int32 dwFlagsAndAttributes，IntPtr hTemplateFile）

在 System.IO.FileStream.Init（字符串路径、FileMode 模式、FileAccess 访问、Int32 权限、Boolean useRights、FileShare 共享、Int32 bufferSize、FileOptions 选项、SECURITY_ATTRIBUTES secAttrs、String msgPath、Boolean bFromProxy、Boolean useLongPath）

在 System.IO.FileStream..ctor（字符串路径，FileMode 模式，FileAccess 访问，FileShare 共享，Int32 bufferSize，FileOptions 选项，字符串 msgPath，布尔 bFromProxy）

在 System.IO.FileStream..ctor（字符串路径，FileMode 模式）