不使用using()DB连接的后果

由于using是调用Dispose的简写，因此可以用try/finally来模仿它。所以真正的问题是根本不调用Dispose的结果是什么。

尽管C#有垃圾收集，在大多数时候最终会释放资源，但您希望在使用完关键资源后立即释放它们。如果使用using或等效的try/finally，则资源会很快释放。如果你让垃圾收集器为你释放资源，你的程序在GC"托管"期间可能会缺乏资源（即你的程序不再使用它们，但GC还没有释放它们）。此外，由于GC没有提供运行终结器的硬性保证，所以在程序结束之前，一些资源可能不会显式释放，这可能会导致其他进程的资源不足。

您不知道.net的垃圾收集器何时被调用和运行，所以它允许您在不需要的时候自己做。因此，当您的代码退出using（）时，它会处理using（（）中使用的对象，而不是等待GC按自己的计划运行。

如果您不与DB连接一起使用，那么GC将根据其实现的算法的标准自行处理它。（就计算机时钟而言）扫描它可能为时已晚。

垃圾收集器是一个后台线程，它不是每毫秒运行一次。它有特定的时间表和自己的算法，倾向于在特定的时间工作。例如，一些GC算法检查没有引用的对象，然后在GC运行时扫描这些对象。

特别是对于数据库连接、语句和结果集每个都需要using（）？如果他们被留下会发生什么后面没有using（）、dispose（）也没有close（）？

实际上，内存泄漏的最严重后果是在重新启动电脑之前保留一些内存。然而，在这种情况下，最严重的后果可能是在重新开始应用程序之前泄漏内存。

如果内存增长到GC无法再清理的程度，事实上，如果小对象堆的第2代溢出（大对象堆也可能溢出），它将抛出内存不足异常并关闭应用程序。

.Net有它的垃圾收集器。它如何处理缺少偶极（）？

所有与数据库连接相关的标准类都正确地实现了Dispose和Finalize方法。通常，这些类中存在非托管资源。未管理的资源是资源（例如：文件处理程序、数据库连接处理程序等），这些资源可能会导致更严重的内存泄漏，在重新启动电脑之前可能会占用内存。然而，GC的最终确定很方便。如果不为此类Disposable对象调用Dispose，垃圾收集器将执行Finalize方法（如果存在~destructor）并清除非托管资源。

这就是为什么需要根据需要正确地实现IDispose模式Dispose和Finalization的原因。只有当具有未管理的资源时，才需要定案。

未能及时Dispose数据库对象最有可能的后果是，程序将要求数据库服务器代表其打开数据库连接，并承诺在不再需要数据库连接时通知服务器（即关闭它们），但在不再需要连接后，可能会让连接打开很长一段时间。这种行为可能会增加数据库服务器需要同时保持打开的连接数量。根据服务器的不同，可能不会产生任何后果，或者额外的连接可能会影响性能，或者可能会导致某些连接请求被不必要地拒绝。

尽管.NET会努力确保数据库服务器在放弃数据库对象时得到通知，但即使不调用Dispose，使用数据库对象的代码通常也会知道何时不再需要它们，早在.NET确定它们被放弃之前。还要注意的是，虽然一些.NET数据库相关库可以在CCD_，而不是依赖于垃圾收集器（这可能会持续很长时间而没有注意到对象已被放弃）。