显然，作为一个原则，我们应该自己清理。在Windows 2000时代之前，我们这些人都知道内存泄漏对用户造成的痛苦。但我很好奇泄漏处理对其他系统资源的影响可能是什么。
这将是未封闭的文件或数据库连接。真的在.net中可以使用的任何东西。我们是Windows商店，但我也会对其他操作系统感兴趣。
我可以使用什么论据让团队成员更认真地对待这一点，或者在现代系统中有更大的鱼来炒？
答案 0 :(得分：1)
这实际上取决于资源是什么。
某些资源几乎只会影响您自己的流程。打开文件句柄在您的过程中受到限制，但是通过泄漏它们对整个系统影响不大。如果您有一个长时间运行的过程（例如服务器或GUI应用程序），那么清理它们很重要，但对于一次性运行的作业，它并不重要。当您的流程关闭时，无论如何都会清理这些资源。
某些资源会影响其他流程。数据库通常具有非常低的连接限制（有时由于许可限制）。如果您在完成连接后没有正确关闭连接，则会很快耗尽非常。此外，打开的连接会占用数据库服务器的资源，因此可能会降低所有用户的速度。此外，这些资源也可能无法在进程关闭时回收，因为操作系统不知道它们;相反，连接可能最终会在服务器上超时，但这可能比您的进程运行时间长得多。
答案 1 :(得分：1)
而不是将资源视为＆＃34;事物＆＃34;要被发布＆＃34;，最好将IDisposable对象的获得视为一项责任。许多IDisposable个对象要求外部实体代表他们做事，直到他们通知这些实体不再需要他们的服务;通过这样做，他们有责任确保那些外部实体事实上得到这样的通知。在Dispose上调用IDisposable时，它可以负责通知其使用过的服务不再需要这些服务。
如果系统注意到他们已被放弃，则对象可以请求通知。接收此类通知的对象通常可以假设不再需要他们的服务，并通知他们一直使用其服务的任何人。在某些情况下，这种机制可以正常工作，但它不应被视为可靠，因为各种因素可能会阻止系统注意到某个对象已被有效放弃。
至于未能调用Dispose的后果，它非常简单：由于对象的服务不再需要而应该发生的事情不会发生。如果一个对象应该通知其他对象或实体不再需要它们的服务，并且它们又被认为通知其他对象或实体，那么这些通知都不会发生。
除了在某些情况下，代码将在程序的生命周期中使用托管资源，并且可以依赖操作系统识别程序的终止，作为程序不再需要其服务的指示，它将通常更容易在不再需要的事情上调用Dispose，无论他们是否真的关心＆＃34;，而不是试图找出导致重大问题导致重大问题的案例。实体通知所有关心不再需要其服务的内容。