SqlConnection 会被 GC 处理掉吗？
免责声明：我知道在处理非托管资源时应该实现IDisposable。代码的其余部分应该是确定性的，并执行 using (...) { } （相当于 try {} finally { Dispose(); }）来保证清理尽快地。此外，GC 将不会调用Dispose()，因此推荐的模式是重写 Finalize() 方法（在 C# 中使用析构函数语法），然后调用 Dispose()。 GC 通常会调用 Finalize()（除非已调用 GC.SuppressFinalize()）。
问题：现在我已经解决了这个问题，我遇到了一个奇怪的情况，由于代码超出了以下范围，我无法使用 (SqlConnection...) { }我的控制。我通常可以执行确定性的 Dispose()，但不能保证它。我使用 Reflector 反汇编了 SqlConnection 并看到它使用了 Dispose()，但除非我是盲人，否则没有终结器/析构函数（Finalize() 或 ~ SqlConnection())。这是否意味着 GC 在我不能的奇怪情况下不会“清理”（发送回池）连接？我还没能找到任何明确的东西......
Disclaimer: I know IDisposable should be implemented when dealing with unmanaged resources. The rest of the code should be deterministic and do using (...) { } (equivalent of try {} finally { Dispose(); }) to guarantee a cleanup as soon as possible. Also, the GC will not call Dispose(), so the recommended pattern is to override the Finalize() method (in C# using the destructor syntax) which then calls Dispose(). The GC will usually call Finalize() (unless GC.SuppressFinalize() has been called).
Problem: So now that I got that out of the way, I have an odd scenario where I cannot do using (SqlConnection...) { } due to code out of my control. I can usually do a deterministic Dispose(), but can't guarantee it. I used Reflector to disassemble SqlConnection and see that it uses Dispose(), but unless I'm blind there is no finalizer/destructor (Finalize() or ~SqlConnection()). Does that mean that the GC will not "clean up" (send back to the pool) the connection in the odd case I can't? I haven't been able to find anything definitive...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
嗯，它不会被处置，因为最终确定不是处置。
System.ComponentModel.Component中有一个终结器，但它在SQLConnection的构造函数中被抑制。如果您从带有终结器的东西继承，并且您 100% 确定您不需要，那么这是一个好主意，但否则就是一个坏主意。在这种情况下，这是一个好主意。但请记住，
SqlConnection是“真实”连接的包装器。事实上，它很可能是一组不断变化的对象的包装器，这些对象代表不同的连接状态。这是允许有效地池化“真实”连接的机制的一部分，因为每次调用Open()时，它都会从池中获取相关对象，并且每次调用>Close()（无论是直接通过Dispose()还是通过离开using的范围）它都会返回它。现在，请记住，只有直接持有非托管资源或 GC 不关心的其他内容的对象才需要最终确定。
SqlConnection保存一个对象，该对象可能（取决于SqlConnection的状态）保存非托管资源（或者实际上，通过类嵌套更深入）。因此，SqlConnection本身无需最终确定。考虑开放式SqlConnection停止成为开放式SqlConnection的三种可能方式：Close()。这会立即将实际连接返回到池中（如果没有池，则关闭它）。Dispose()。这调用Close()具有相同的效果。现在，在第三种情况下，该对象保存对具有实际连接的对象的引用。它也是唯一这样做的对象。因此，该对象也将被垃圾收集。如果它有一个终结器（它可能有，尽管我不会假设没有进一步的巧妙技巧），那么该终结器将导致它被放入终结器队列中，并且最终将被终结。
如果
SqlConnection有终结器，唯一真正的影响是：因此，在
SqlConnection上放置终结器是一种没有胜利的失败。此外，您的真正联系应该最终会完成。也就是说，它仍然远非理想，并且仍然非常可能泄漏连接。您能否详细说明为什么您无法调用
Close()或自行处置？管理连接的代码是否可以不为您调用 close（对象应该在某个地方结束其生命，并且应该在那里关闭）？您是否需要使其保持活动状态，以便
IDataReader或从IDataReader提供数据的对象才能完成？在这种情况下，您可以使用 CommandBehavior.CloseConnection 标志以便关闭（或处置）读取器来关闭连接吗？后一种情况是我记得的唯一一种必须让连接离开未处理范围的情况。Well, it won't get disposed, as finalisation is not disposal.
There is a finaliser in
System.ComponentModel.Component, but its suppressed inSQLConnection's constructor. This is a good idea if you inherit from something with a finaliser that you know with 100% certainty you won't need, but a bad idea otherwise. In this case it's a good idea.Remember though, that
SqlConnectionis a wrapper on a "real" connection. Indeed, it's most likely a wrapper on a changing set of objects which represent different connection states. This is part of the mechanism that allows for the "real" connection to be pooled efficiently, as each time you callOpen()it obtains the relevant object from the pool, and every time you callClose()(whether directly, byDispose()or by leaving the scope of ausing) it returns it.Now, remember that only objects that directly hold an unmanaged resource or something otherwise not the GC's concern, need to be finalised.
SqlConnectionholds an object that may (depending on the state ofSqlConnection) be one that holds an unmanaged resource (or indeed, deeper through the nest of classes). There is therefore no need forSqlConnectionto itself be finalised. Consider the three possible ways an openSqlConnectioncan stop being an openSqlConnection:Close()is called. This immediately returns the real connection to the pool (or closes it if there is no pooling).Dispose()is called. This callsClose()with the same effect.Now, in the third case, the object holds a reference to the object that has the real connection. It also is the only object that does so. That object is hence also going to be garbage collected. If it has a finaliser (which it probably does, though I'm not going to assume there aren't further clever tricks going on) then that finaliser will cause it to be placed into the finaliser queue, and it will be eventually finalised.
If
SqlConnectionhad a finaliser, the only real effects would be:So, putting a finaliser on the
SqlConnectionis a lose without a win. Also, your real connection should hopefully be eventually finalised.This said, it's still far from ideal and still very likely to leak connections. Could you detail precisely why you can't call
Close()or dispose yourself? Could the code managing the connection not call close for you (the object should end its days somewhere, and should be closed there)?Do you need to keep it alive for an
IDataReaderor an object that feeds from anIDataReaderto be allowed to complete? In which case, could you use theCommandBehavior.CloseConnectionflag so that closing (or disposing of) the reader closes the connection? This latter case is about the only case where I can recall ever having to let a connection leave scope un-disposed.