是否有时间忽略IDisposable.Dispose？

Question

当然我们应该在IDisposable对象上调用Dispose(),一旦我们不需要它们(通常只是"using"语句的范围).如果我们不采取这种预防措施,那么可能会发生从细微到显示停止的坏事.

但是在流程终止之前的"最后时刻"呢？如果您的IDisposables在那个时间点没有明确处理,那么它不再重要吗？我问,因为CLR下面的非托管资源由内核对象表示 - 而win32进程终止将释放所有非托管资源/内核对象.换句话说,在进程终止后,任何资源都不会被"泄露"(无论是否在延迟的IDisposables上调用Dispose()).

任何人都可以想到一个过程终止仍会留下泄漏资源的情况,仅仅因为没有在一个或多个IDisposables上显式调用Dispose()？

请不要误解这个问题:我并不是在试图忽视IDisposables.问题只是技术理论上的问题.

编辑:那么在Linux上运行单声道怎么样？在清理未管理的"泄漏"时,流程终止是否"可靠"？

晚编辑:虽然IDisposables可能存在"其他用途",但我的重点是资源泄漏.我听到了两个答案:(1)如果你的进程拒绝终止,你就会泄漏;(2)是的,即使进程终止,资源也可能泄漏.我当然同意第(1)项,尽管它超出了我所追求的范围.否则,第(2)项正是我正在寻找的,但我无法摆脱这只是猜测的感觉.Jeffrey Richter("通过C/C++的Windows")解释说,(优雅地)终止的Win32进程不会留下泄漏或孤立的资源.为什么包含CLR的进程会改变这种情况？在使用CLR时,文档,特定示例或理论场景在哪里可以说明Win32进程清理功能受到损害？

Answer 1

从技术上讲，这完全取决于 IDisposable 的作用。它已被用于很多事情，而不仅仅是非托管资源。

例如，在开发 Outlook 应用程序时，我构建了 Outlook API 的一个很好的小抽象。附件作为流使用时特别烦人，因为您需要将其保存到临时文件中，使用它，然后清理它。

所以我的抽象看起来像这样：

OutlookMailItem mailItem = blah;
using (Stream attachmentStream = mailItem.OpenAttachment("something.txt")) {
   // work with stream
}

当对 AttachmentStream 调用 Dispose 时，它​​所基于的临时文件被删除。在这种情况下，如果不调用 Dispose，临时文件将永远不会被清理。我在启动时有一个过程来查找这些孤立的文件，但我想我应该将此作为一个例子。

实际上，几乎所有包装某种套接字、句柄或事务的 IDisposable 实现都会在进程终止时被操作系统简单地清除。但显然这就像福利。如果可以的话避免它。